From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 13 11:13:20 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:20 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:20 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:20 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 13 11:13:20 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:20 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 11:13:20 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:20 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 11:13:20 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:20 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 11:13:20 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:13:53 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 13 15:21:15 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:15 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:15 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:15 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 13 15:21:15 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:15 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:21:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:21:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:21:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 13 16:00:48 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:48 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:48 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:48 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 13 16:00:48 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:48 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 16:00:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 16:00:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 16:00:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 13 20:01:38 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:38 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:38 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:38 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 13 20:01:38 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:38 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 20:01:38 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:38 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 20:01:39 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:39 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 20:01:39 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 08:02:20 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 12:00:45 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 14 16:00:44 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:44 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:44 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:44 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 14 16:00:44 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:44 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 16:00:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 16:00:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 16:00:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 20:00:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 15 08:02:07 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:07 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:07 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:07 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 15 08:02:07 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:07 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 08:02:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 08:02:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 08:02:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 15 12:00:50 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 12:00:52 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 16:00:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 15 20:00:43 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:43 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:43 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:43 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 15 20:00:43 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:43 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 20:00:43 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:43 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 20:00:43 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:43 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 20:00:43 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 16 08:02:29 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:29 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:29 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:29 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 16 08:02:29 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:29 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 08:02:29 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:29 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 08:02:29 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:30 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 08:02:30 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 16 12:00:48 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:48 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:48 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:48 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 16 12:00:48 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:48 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 12:00:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 12:00:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 12:00:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 16:00:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 20:00:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 17 08:02:32 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:32 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:32 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:32 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 17 08:02:32 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:32 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 08:02:32 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:32 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 08:02:32 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:32 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 08:02:32 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 17 12:01:01 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:01 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 17 12:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 12:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 12:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 12:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 17 16:00:48 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 16:00:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 17 20:00:51 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:51 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:51 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:51 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 17 20:00:51 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:51 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 20:00:51 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:51 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 20:00:51 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:51 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Jan 18 08:04:16 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:16 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:16 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:16 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Jan 18 08:04:16 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:16 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 08:04:16 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:16 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 08:04:16 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:16 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 08:04:16 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Jan 18 12:01:01 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:01 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Jan 18 12:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 12:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 12:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 12:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Jan 18 16:01:27 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:27 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:27 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:27 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Jan 18 16:01:27 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:27 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 16:01:28 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:28 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 16:01:28 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:28 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 16:01:28 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Jan 18 20:00:54 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:55 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:55 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:55 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Jan 18 20:00:55 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:55 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 20:00:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 20:00:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 20:00:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Jan 19 08:04:37 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:37 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:37 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:37 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Jan 19 08:04:37 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:37 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 08:04:37 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:37 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 08:04:37 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:37 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 08:04:37 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Jan 19 12:00:59 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:59 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:59 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:59 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Jan 19 12:00:59 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:59 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 12:00:59 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:59 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 12:00:59 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 12:00:59 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 12:00:59 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Jan 19 16:02:54 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:54 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Jan 19 16:02:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 16:02:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 16:02:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 16:02:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 16:02:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 20:00:49 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 20 08:06:47 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:48 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:48 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:48 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 20 08:06:48 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:48 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 08:06:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 08:06:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 08:06:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 08:06:48 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 20 12:02:02 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:02 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 20 12:02:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 12:02:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 12:02:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 12:02:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 20 16:00:51 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:51 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:51 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:51 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 20 16:00:51 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:51 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 16:00:51 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:51 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 16:00:51 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:51 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 16:00:51 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 20:00:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 21 08:03:52 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:52 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:52 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:52 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 21 08:03:52 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:52 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 08:03:52 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:52 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 08:03:52 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:52 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 08:03:52 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 12:01:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 21 16:00:51 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:51 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:51 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:51 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 21 16:00:51 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:51 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 16:00:51 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:51 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 16:00:51 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 20:00:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 22 08:02:44 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:44 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:44 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:44 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 22 08:02:44 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:44 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 08:02:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 08:02:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 08:02:45 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 22 12:00:50 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:50 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:50 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:50 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 22 12:00:50 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:50 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 12:00:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 12:00:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 12:00:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 22 16:01:20 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:20 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:20 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:20 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 22 16:01:20 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:20 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 16:01:20 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:20 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 16:01:20 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:20 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 16:01:20 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 22 20:01:14 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:14 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:14 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:14 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 22 20:01:15 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:15 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 20:01:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 20:01:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 20:01:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 23 08:02:41 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:41 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:41 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:41 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 23 08:02:41 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:41 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 08:02:41 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:41 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 08:02:41 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:41 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 08:02:41 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 23 12:00:56 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:56 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:56 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:56 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 23 12:00:56 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:56 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 12:00:56 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:56 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 12:00:56 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:56 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 12:00:56 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 23 16:01:45 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:45 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:45 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:45 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 23 16:01:45 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:45 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 16:01:45 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:45 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 16:01:45 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:46 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 16:01:46 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 20:00:52 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 24 08:03:08 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:09 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:09 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:09 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 24 08:03:09 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:09 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 08:03:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 08:03:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 08:03:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 24 12:02:53 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:53 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:53 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:53 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 24 12:02:53 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 12:02:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 12:02:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 12:02:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 12:02:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 24 16:01:20 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:21 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:21 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:21 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 24 16:01:22 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:22 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 16:01:22 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:22 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 16:01:22 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:22 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 16:01:22 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 24 20:01:54 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:54 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 24 20:01:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 20:01:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 20:01:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 20:01:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Jan 25 08:02:01 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:01 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Jan 25 08:02:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 08:02:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 08:02:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 08:02:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Jan 25 12:01:01 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:01 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Jan 25 12:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 12:01:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Jan 25 16:01:00 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:00 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Jan 25 16:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 16:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 16:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 16:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Jan 25 20:00:53 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:53 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:53 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:53 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Jan 25 20:00:53 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:53 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 20:00:53 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:53 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 20:00:53 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:53 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 20:00:53 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Jan 26 08:05:40 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:40 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:40 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:40 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Jan 26 08:05:41 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:41 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 08:05:41 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:41 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 08:05:41 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:41 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 08:05:41 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Jan 26 12:01:05 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:05 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:05 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:05 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Jan 26 12:01:05 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:05 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 12:01:05 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:05 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 12:01:06 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 16:00:53 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 20:00:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 27 08:06:37 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:38 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:38 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:38 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 27 08:06:38 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:38 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 08:06:38 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:38 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 08:06:38 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:39 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 08:06:39 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 27 12:02:10 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:10 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:10 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:10 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 27 12:02:10 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:10 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 12:02:10 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:10 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 12:02:10 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:10 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 12:02:10 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 27 16:01:06 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 16:01:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 20:00:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 28 08:05:36 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:36 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:36 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:36 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 28 08:05:36 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:36 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 08:05:36 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:36 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 08:05:36 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:36 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 08:05:37 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 28 12:01:54 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:54 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 28 12:01:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 12:01:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 12:01:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 12:01:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 28 16:00:54 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:54 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 28 16:00:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 16:00:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 16:00:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 16:00:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 28 20:00:56 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:56 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:56 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:56 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Jan 28 20:00:56 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:56 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 20:00:56 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:56 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 20:00:56 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:56 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 20:00:56 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 29 08:07:30 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:31 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:31 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:31 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 29 08:07:31 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:31 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 08:07:31 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:31 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 08:07:31 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:31 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 08:07:31 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 12:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 29 16:00:53 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 16:00:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 20:00:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 30 08:08:41 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:42 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:42 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:42 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 30 08:08:42 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:42 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 08:08:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 08:08:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 08:08:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 30 12:03:54 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:54 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 30 12:03:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:54 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 12:03:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 12:03:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 12:03:54 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 30 16:04:08 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:08 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:08 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:08 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 30 16:04:08 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:08 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 16:04:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 16:04:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 16:04:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 30 20:02:12 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:12 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:13 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:13 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Jan 30 20:02:13 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:13 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 20:02:13 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:13 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 20:02:13 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:13 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 20:02:13 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 31 08:07:49 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:49 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:49 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:49 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 31 08:07:49 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:49 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 08:07:49 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:49 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 08:07:49 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:49 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 08:07:49 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 31 12:04:15 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:15 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:15 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:15 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 31 12:04:15 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:15 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 12:04:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 12:04:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 12:04:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 31 16:02:16 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:16 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:16 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:16 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 31 16:02:16 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:16 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 16:02:16 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:16 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 16:02:16 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:19 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 16:02:19 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 31 20:01:08 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:08 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:08 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:08 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Jan 31 20:01:08 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:08 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 20:01:08 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:08 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 20:01:08 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:08 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 20:01:08 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 1 08:09:34 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:34 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:34 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:34 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 1 08:09:35 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:35 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 08:09:35 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:35 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 08:09:35 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:35 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 08:09:35 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 1 12:02:42 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:43 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:43 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:43 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 1 12:02:43 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:43 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 12:02:43 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:43 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 12:02:43 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:43 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 12:02:43 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 1 16:01:06 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:06 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 1 16:01:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 16:01:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 20:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Feb 2 08:12:24 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:25 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:25 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:25 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Feb 2 08:12:26 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:26 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 08:12:26 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:26 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 08:12:26 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:26 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 08:12:26 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Feb 2 12:02:47 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:47 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:47 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:47 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Feb 2 12:02:47 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:47 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 12:02:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 12:02:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 12:02:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 16:01:11 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Feb 2 20:01:00 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:00 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Feb 2 20:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 20:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 20:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 20:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Feb 3 08:12:02 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:03 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:03 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:03 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Feb 3 08:12:03 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:03 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 08:12:04 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:04 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 08:12:04 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:04 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 08:12:04 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Feb 3 12:02:39 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:39 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:39 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:39 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Feb 3 12:02:39 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:39 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 12:02:39 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:39 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 12:02:40 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:40 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 12:02:40 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Feb 3 16:01:01 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:01 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Feb 3 16:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 16:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 16:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 16:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Feb 3 20:01:06 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:06 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Feb 3 20:01:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 20:01:06 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:06 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 20:01:06 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 20:01:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Feb 4 08:07:47 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:48 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:48 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:48 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Feb 4 08:07:50 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:50 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 08:07:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 08:07:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 08:07:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 08:07:50 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Feb 4 12:02:42 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:42 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:42 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:42 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Feb 4 12:02:42 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:42 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 12:02:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 12:02:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 12:02:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Feb 4 16:01:12 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:12 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:12 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:12 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Feb 4 16:01:12 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:12 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 16:01:12 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:12 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 16:01:13 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Feb 4 20:01:02 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:02 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Feb 4 20:01:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 20:01:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 20:01:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 20:01:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Feb 5 08:07:55 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:55 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:55 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:55 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Feb 5 08:07:55 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:55 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 08:07:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 08:07:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 08:07:55 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Feb 5 12:02:42 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:42 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:42 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:42 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Feb 5 12:02:42 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:42 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 12:02:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 12:02:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 12:02:42 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Feb 5 16:01:06 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:06 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Feb 5 16:01:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 16:01:06 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:06 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 16:01:06 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 16:01:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 20:00:59 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Feb 6 08:14:40 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:14:43 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:14:43 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:14:44 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Feb 6 08:14:44 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:14:44 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 08:14:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:14:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 08:14:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 08:14:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 08:14:44 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Feb 6 12:02:40 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:40 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:41 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:41 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Feb 6 12:02:41 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:41 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 12:02:41 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:41 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 12:02:41 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:41 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 12:02:41 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 16:01:05 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Feb 6 20:01:00 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:00 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Feb 6 20:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 20:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 20:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 20:01:00 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Feb 7 08:22:57 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:22:59 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:22:59 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:22:59 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Feb 7 08:22:59 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:22:59 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 08:22:59 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:22:59 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 08:22:59 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 08:22:59 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 08:22:59 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Feb 7 12:03:16 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:17 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:17 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:17 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Feb 7 12:03:17 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:17 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 12:03:17 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:17 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 12:03:17 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:17 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 12:03:17 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Feb 7 16:01:08 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:08 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:08 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:08 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Feb 7 16:01:08 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:08 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 16:01:08 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:08 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 16:01:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Feb 7 20:01:03 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:03 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:03 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:03 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Feb 7 20:01:03 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:03 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 20:01:03 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:05 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 20:01:05 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:05 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 20:01:05 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 8 08:22:09 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:10 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:10 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:10 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 8 08:22:10 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:10 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 08:22:10 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:10 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 08:22:10 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:10 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 08:22:11 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 8 12:03:21 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:21 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:21 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:21 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 8 12:03:21 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:21 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 12:03:21 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:21 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 12:03:22 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:22 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 12:03:22 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 8 16:01:14 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:14 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:14 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:14 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 8 16:01:14 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:14 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 16:01:14 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:14 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 16:01:14 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:14 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 16:01:14 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 8 20:01:04 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:04 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:04 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:04 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 8 20:01:04 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:04 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 20:01:04 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:04 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 20:01:04 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:04 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 20:01:04 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Feb 9 08:09:10 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:10 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:10 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:10 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Feb 9 08:09:10 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:10 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 08:09:10 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:10 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 08:09:10 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:11 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 08:09:11 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Feb 9 12:03:07 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:07 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:07 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:07 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Feb 9 12:03:07 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:07 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 12:03:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 12:03:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:08 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 12:03:08 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Feb 9 16:01:15 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:15 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:15 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:15 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Feb 9 16:01:15 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:15 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 16:01:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 16:01:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 16:01:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Feb 9 20:01:09 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:09 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:09 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:09 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Feb 9 20:01:09 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:09 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 20:01:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 20:01:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 20:01:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Feb 10 08:19:34 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:36 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:36 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:37 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Feb 10 08:19:37 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:37 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 08:19:37 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:37 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 08:19:37 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 08:19:37 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 08:19:37 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Feb 10 12:03:37 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:37 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:37 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:37 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Feb 10 12:03:37 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:37 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 12:03:37 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:37 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 12:03:37 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:37 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 12:03:37 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 16:01:09 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Feb 10 20:01:12 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:12 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:12 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:12 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Feb 10 20:01:12 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:12 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 20:01:12 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:12 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 20:01:12 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:12 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 20:01:13 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Feb 11 08:12:46 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:46 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:46 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:47 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Feb 11 08:12:47 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:47 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 08:12:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 08:12:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 08:12:47 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Feb 11 12:02:37 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:38 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:38 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:38 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Feb 11 12:02:38 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:38 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 12:02:38 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:38 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 12:02:38 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:38 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 12:02:38 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 16:01:04 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 20:00:57 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Feb 12 08:09:14 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:15 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:15 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:15 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Feb 12 08:09:15 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:15 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 08:09:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 08:09:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 08:09:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Feb 12 12:02:46 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:46 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:46 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:46 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Feb 12 12:02:46 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:46 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 12:02:46 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:46 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 12:02:46 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:46 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 12:02:46 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 16:01:10 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Feb 12 20:01:00 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:00 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:00 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Sun Feb 12 20:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 20:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 20:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 20:01:01 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Feb 13 08:16:48 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:49 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:49 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:49 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Feb 13 08:16:49 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:49 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 08:16:49 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:49 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 08:16:49 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 08:16:49 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 08:16:49 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Feb 13 12:03:05 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:05 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:05 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:05 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Feb 13 12:03:05 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:05 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 12:03:05 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:05 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 12:03:05 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:05 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 12:03:05 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Feb 13 16:01:23 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:23 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:23 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:23 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 16:01:24 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Feb 13 20:01:06 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:06 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Mon Feb 13 20:01:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 20:01:06 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:06 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 20:01:06 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:06 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 20:01:06 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Feb 14 08:19:06 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:06 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Feb 14 08:19:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:06 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 08:19:06 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 08:19:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 08:19:07 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Feb 14 12:03:21 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:21 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:21 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:21 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Feb 14 12:03:21 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:21 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 12:03:21 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:21 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 12:03:21 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:21 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 12:03:21 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Feb 14 16:01:31 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:31 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:31 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:31 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Feb 14 16:01:31 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:31 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 16:01:31 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:31 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 16:01:31 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:31 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 16:01:32 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Feb 14 20:01:12 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:12 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:12 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:12 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Tue Feb 14 20:01:12 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:12 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 20:01:12 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:12 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 20:01:12 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:12 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 20:01:12 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 15 08:27:11 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:14 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:14 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:14 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 15 08:27:14 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:14 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 08:27:14 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:14 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 08:27:14 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:14 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 08:27:15 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 15 12:05:23 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:23 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:23 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:24 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 15 12:05:24 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:24 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 12:05:24 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:24 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 12:05:24 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:24 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 12:05:24 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 15 16:01:31 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:33 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:33 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:34 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 15 16:01:34 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:34 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 16:01:34 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:34 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 16:01:34 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:34 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 16:01:34 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 15 19:28:02 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:02 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 15 19:28:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 19:28:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 19:28:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 19:28:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 15 20:13:22 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:23 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:23 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:23 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Wed Feb 15 20:13:23 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:23 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 20:13:23 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:23 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 20:13:23 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:23 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 20:13:23 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Feb 16 08:46:00 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:01 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:02 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Thu Feb 16 08:46:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:02 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 16 08:46:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 16 08:46:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 16 08:46:02 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From Tim.Edwards at hwe.com.au Fri Nov 7 12:05:54 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Mar 31 16:33:38 2006 Subject: [egenix-users] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: Hi, We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the database connection sometimes freezes the Zope instance. When this occurs it becomes difficult to access the Zope management interface - we keep getting 'Cannot Find Server' messages in the frames, with it only loading a frame correctly on every 2nd or 3rd refresh. Once we manage to get into the folder that has the database connection and click the 'Close Connection' button on the status page Zope returns to normal. Has anyone experienced problems like this? The following was pasted from the Status page of the connection: Connection Options * Database Warnings are reported as Python exceptions. * Connection uses auto-commit. * Time columns are returned as DateTime values. * Date/time columns are returned as Zope DateTime values. * Short integers are fetched as short integers. * Scale 0 floats are converted to integers. * The first available result set is fetched in queries. Connection Pool Pool size: 1 Physical connections: 0 open Tim Edwards From mal at lemburg.com Sat Nov 8 12:20:58 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:38 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FACD19A.7040504@lemburg.com> Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sat Nov 8 12:24:27 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:38 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: <16300.5213.833164.287341@gargle.gargle.HOWL> References: <16300.5213.833164.287341@gargle.gargle.HOWL> Message-ID: <3FACD26B.9010803@lemburg.com> Dieter Maurer wrote: > Tim Edwards wrote at 2003-11-7 12:05 +1100: > > ... > > The problem is that the > > database connection sometimes freezes the Zope instance. When this occurs it > > becomes difficult to access the Zope management interface - we keep getting > > 'Cannot Find Server' messages > > What a strange message. Never heard of something like this. > > It does not sound like a Zope problem but more like a DNS problem. > But not all programs generate error messages that give a good > clue to the error cause... One possible reason could be that the ODBC driver has problems finding the MS SQL Server on the network. To avoid this, it is usually a good idea to put the name - IP mapping for the SQL Server machine directly into the /etc/hosts file on the Linux machine, provided that the mapping doesn't change too often. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Sun Nov 9 23:32:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:38 2006 Subject: [egenix-users] eGenix mxODBC Zope DA 1.0.7 pre-release Message-ID: <3FAEC085.4080507@lemburg.com> Hi, We've been working on a fix for the problems that some of our users have seen esp. with MS SQL Server where Zope would deadlock with certain query setups under heavy loads and situations where multiple Z SQL Methods were being used within a single request. The beta version we are making available here uses a more restricted way of implementing the connection pool that assures that physical connections cannot be used outside their original thread context (this should help with the MS SQL Server problems) and bind usage of the connections to a single request (fixing the multiple Z SQL Methods problem). Note that the pool size is now considered only a guideline for the DA. Under heavy load, the pool size will go up to the number of Zope threads serving requests. The DA will try to trim the size down to the set pool size again as soon as the load goes down as well. Please give the beta a try and tell us whether it fixes your problems, if any. The 1.0.x eval and production licenses will also work with this version. These are the available download links: http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.2.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.3.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.linux-i686-py2.4.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py1.5.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.1.zip http://www.egenix.com/files/python/egenix-mxodbc-zopeda-1.0.7.b1.win32-py2.2.zip Binaries for Solaris and FreeBSD will be available for the release version. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 09 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Tim.Edwards at hwe.com.au Mon Nov 10 10:20:44 2003 From: Tim.Edwards at hwe.com.au (Tim Edwards) Date: Fri Mar 31 16:33:38 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Message-ID: We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server database. We are running select, update and delete queries - not nested, just simple queries. The problem seems to occur when we have more than one egenix mxODBC connection object open at a time. Using the Zope management interface I have tried opening more than one connection at a time. When I do this the Zope server becomes unresponsive (as described below in 1st email) and then returns to normal after 10-15 seconds. However the connection that I tried to open is closed. If I close all connections and then try to open one it works fine. If I then try to open another it does this. Any help greatly appreciated -----Original Message----- From: M.-A. Lemburg [mailto:mal@lemburg.com] Sent: Saturday, 8 November 2003 10:21 PM To: Tim Edwards Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope Tim Edwards wrote: > Hi, > > We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from > Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the > database connection sometimes freezes the Zope instance. Can you provide more background information about the kinds of queries you are running ? It is also important to know about the ODBC driver you are using to access MS SQL Server from Linux. > When this occurs it > becomes difficult to access the Zope management interface - we keep getting > 'Cannot Find Server' messages in the frames, with it only loading a frame > correctly on every 2nd or 3rd refresh. Once we manage to get into the folder > that has the database connection and click the 'Close Connection' button on > the status page Zope returns to normal. > > Has anyone experienced problems like this? > > The following was pasted from the Status page of the connection: > Connection Options > * Database Warnings are reported as Python exceptions. > * Connection uses auto-commit. > * Time columns are returned as DateTime values. > * Date/time columns are returned as Zope DateTime values. > * Short integers are fetched as short integers. > * Scale 0 floats are converted to integers. > * The first available result set is fetched in queries. > Connection Pool Pool size: 1 > Physical connections: 0 open -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 08 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at lemburg.com Mon Nov 10 10:21:03 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:38 2006 Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server 2000 freezes Zope In-Reply-To: References: Message-ID: <3FAF587F.4090205@lemburg.com> Tim Edwards wrote: > We are using the FreeTDS v0.61 driver to connect unixODBC to the SQL Server > database. We are running select, update and delete queries - not nested, > just simple queries. The problem seems to occur when we have more than one > egenix mxODBC connection object open at a time. > > Using the Zope management interface I have tried opening more than one > connection at a time. When I do this the Zope server becomes unresponsive > (as described below in 1st email) and then returns to normal after 10-15 > seconds. However the connection that I tried to open is closed. If I close > all connections and then try to open one it works fine. If I then try to > open another it does this. > > Any help greatly appreciated This sounds like a problem with the FreeTDS driver. Please try out the 1.0.7 beta I posted yesterday and see if it helps. We've made the connection pooling a bit more restrictive and that should help drivers that are not 100% thread safe. > -----Original Message----- > From: M.-A. Lemburg [mailto:mal@lemburg.com] > Sent: Saturday, 8 November 2003 10:21 PM > To: Tim Edwards > Cc: 'egenix-users@lists.egenix.com'; 'zope-db@zope.org' > Subject: [egenix-users] Re: [Zope-DB] mxODBC connection to SQL Server > 2000 freezes Zope > > > Tim Edwards wrote: > >>Hi, >> >>We are using mxODBC 1.0.6 to connect to a MS SQL Server 2000 server from >>Zope 2.6.1 running on a Red Hat Linux 8 server. The problem is that the >>database connection sometimes freezes the Zope instance. > > > Can you provide more background information about the kinds of > queries you are running ? It is also important to know about > the ODBC driver you are using to access MS SQL Server from > Linux. > > >>When this occurs it >>becomes difficult to access the Zope management interface - we keep > > getting > >>'Cannot Find Server' messages in the frames, with it only loading a frame >>correctly on every 2nd or 3rd refresh. Once we manage to get into the > > folder > >>that has the database connection and click the 'Close Connection' button > > on > >>the status page Zope returns to normal. >> >>Has anyone experienced problems like this? >> >>The following was pasted from the Status page of the connection: >>Connection Options >>* Database Warnings are reported as Python exceptions. >>* Connection uses auto-commit. >>* Time columns are returned as DateTime values. >>* Date/time columns are returned as Zope DateTime values. >>* Short integers are fetched as short integers. >>* Scale 0 floats are converted to integers. >>* The first available result set is fetched in queries. >>Connection Pool Pool size: 1 >>Physical connections: 0 open > > -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 10 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Nov 16 11:54:12 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Mar 31 16:33:38 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 Message-ID: The subject line pretty much explains the problem. The gory details follow, truncated to remain useful for the clueful (among which I don't count myself in this particular arena): $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtes t.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.iODBC.mxODBC' extension creating build creating build/temp.cygwin-1.5.5-i686-2.3 creating build/temp.cygwin-1.5.5-i686-2.3/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc lude -c mx/ODBC/iODBC/mxSQLCodes.c -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ LCodes.o In file included from /usr/include/w32api/sql.h:13, from mx/ODBC/iODBC/mxODBC.h:239, from mx/ODBC/iODBC/mxSQLCodes.c:17: /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" ... lots more similar problems, then eventually ... In file included from mx/ODBC/iODBC/mxSQLCodes.c:17: mx/ODBC/iODBC/mxODBC.h:718: error: parse error before "SQLCHAR" mx/ODBC/iODBC/mxODBC.h:718: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:721: error: parse error before "sqllen" mx/ODBC/iODBC/mxODBC.h:721: warning: type defaults to `int' in declaration of `sqllen' mx/ODBC/iODBC/mxODBC.h:721: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:727: error: parse error before "data" mx/ODBC/iODBC/mxODBC.h:727: warning: type defaults to `int' in declaration of `data' mx/ODBC/iODBC/mxODBC.h:727: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:733: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:736: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:738: warning: type defaults to `int' in declaration of `mxODBCursor_Variable' mx/ODBC/iODBC/mxODBC.h:738: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:754: error: parse error before "mxODBCursor_Variable" mx/ODBC/iODBC/mxODBC.h:754: warning: no semicolon at end of struct or union mx/ODBC/iODBC/mxODBC.h:767: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:768: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:770: error: parse error before ':' token mx/ODBC/iODBC/mxODBC.h:772: warning: type defaults to `int' in declaration of `mxODBCursorObject' mx/ODBC/iODBC/mxODBC.h:772: warning: data definition has no type or storage class mx/ODBC/iODBC/mxODBC.h:785: error: parse error before '*' token mx/ODBC/iODBC/mxODBC.h:786: warning: function declaration isn't a prototype error: command 'gcc' failed with exit status 1 I suspect this might be the reappearance of a system problem that I've struggled with before on Cygwin, but long enough ago to have forgotten the details. Something to do with C vs C++ and DLL headers? Anyone? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 11:06:31 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:38 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB89DA7.2040307@lemburg.com> Steve Holden wrote: > The subject line pretty much explains the problem. The gory details > follow, truncated to remain useful for the clueful (among which I don't > count myself in this particular arena): > > $ python setup.py install > running install > running build > running mx_autoconf > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc > lude/python2.3 -I/usr/include -c _configtest.c -o _configtes > t.o > success! > removing: _configtest.c _configtest.o > running build_ext > building 'mx.ODBC.iODBC.mxODBC' extension > creating build > creating build/temp.cygwin-1.5.5-i686-2.3 > creating build/temp.cygwin-1.5.5-i686-2.3/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx > creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC > creating > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC > gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DiODBC -Imx/ODBC/iODBC -I > /usr/local/iODBC/include -I/usr/include/python2.3 -I/usr/inc > lude -c mx/ODBC/iODBC/mxSQLCodes.c -o > build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/iODBC/mxODBC/mx/ODBC/iODBC/mxSQ > LCodes.o > In file included from /usr/include/w32api/sql.h:13, > from mx/ODBC/iODBC/mxODBC.h:239, > from mx/ODBC/iODBC/mxSQLCodes.c:17: > /usr/include/w32api/sqltypes.h:17: error: parse error before "UDWORD" > /usr/include/w32api/sqltypes.h:18: error: parse error before "UWORD" > /usr/include/w32api/sqltypes.h:24: error: parse error before "PTR" > /usr/include/w32api/sqltypes.h:25: error: parse error before "HENV" > /usr/include/w32api/sqltypes.h:26: error: parse error before "HDBC" > > ... lots more similar problems, then eventually ... Could you cut&paste the top of sqltypes.h ? It seems that Cygwin has messed up some of these header files... -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 10:42:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Mar 31 16:33:38 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB89DA7.2040307@lemburg.com> Message-ID: [mal] > > Could you cut&paste the top of sqltypes.h ? It seems that > Cygwin has messed up some of these header files... > $ head -24 /usr/include/w32api/sqltypes.h #ifndef _SQLTYPES_H #define _SQLTYPES_H #if __GNUC__ >=3 #pragma GCC system_header #endif #ifdef __cplusplus extern "C" { #endif #define SQL_API __stdcall #ifndef RC_INVOKED #define __need_wchar_t #include typedef signed char SCHAR; typedef long SDWORD; typedef short SWORD; typedef ULONG UDWORD; typedef USHORT UWORD; typedef signed long SLONG; typedef signed short SSHORT; typedef double SDOUBLE; typedef double LDOUBLE; typedef float SFLOAT; typedef PVOID PTR; Is this enough? regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/ From mal at lemburg.com Mon Nov 17 17:33:51 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:38 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: References: Message-ID: <3FB8F86F.8030908@lemburg.com> Steve Holden wrote: > [mal] > >>Could you cut&paste the top of sqltypes.h ? It seems that >>Cygwin has messed up some of these header files... >> > > $ head -24 /usr/include/w32api/sqltypes.h > #ifndef _SQLTYPES_H > #define _SQLTYPES_H > #if __GNUC__ >=3 > #pragma GCC system_header > #endif > > #ifdef __cplusplus > extern "C" { > #endif > #define SQL_API __stdcall > #ifndef RC_INVOKED > #define __need_wchar_t > #include > typedef signed char SCHAR; > typedef long SDWORD; > typedef short SWORD; > typedef ULONG UDWORD; > typedef USHORT UWORD; These are causing the problem it seems: ULONG, USHORT, PVOID, etc. Could be that cygwin needs another header file to be included prior to including sqltypes.h - the one that defines ULONG etc. In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, the following was added to mxODBC.h near the top (line 213): """ /* For cygwin, we need the Windows #defines here in addition to any SQL header files. */ #ifdef __CYGWIN__ # include #endif """ (and the records says that this was suggested by Steve Holden ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Nov 17 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC.Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Mon Nov 17 13:06:47 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Mar 31 16:33:38 2006 Subject: [egenix-users] Cygwin compile problem in commercial 2.0.6 In-Reply-To: <3FB8F86F.8030908@lemburg.com> Message-ID: [mal][...] > > These are causing the problem it seems: ULONG, USHORT, PVOID, etc. > Could be that cygwin needs another header file to be included > prior to including sqltypes.h - the one that defines ULONG etc. > > In mxODBC 2.1.0 which is not available outside the mxODBC Zope DA, > the following was added to mxODBC.h near the top (line 213): > > """ > /* For cygwin, we need the Windows #defines here in addition to any > SQL header files. */ > > #ifdef __CYGWIN__ > # include > #endif > """ > > (and the records says that this was suggested by Steve Holden ;-) > Inserting that code did remove the compilation errors, which were then replaced by futile attempts to use iODBC. I traced this to several spots in the mxCOMMERCIAL.py code where the test for windows was if sys.platform[:3] == 'win': when it really needs to be if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': or similar, I suspect, to catch "cygwin" as the platform as well as "win". Now my problems are somewhat different: sholden@DellBoy ~/egenix-mx-commercial-2.0.6 $ python setup.py install running install running build running mx_autoconf gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/usr/inc lude/python2.3 -I/usr/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o running build_ext building 'mx.ODBC.Windows.mxODBC' extension creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC creating build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC/Windows/mxSQLCodes.cpp -o build/temp.cygwin-1.5.5-i686- .3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/mxSQLCodes.o mx/ODBC/Windows/mxSQLCodes.cpp: In function `PyObject* mxODBC_SQLCodes_lookup(PyObject*, PyObject*)': mx/ODBC/Windows/mxSQLCodes.cpp:6450: warning: comparison between signed and unsigned integer expressions gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -DMS_ODBC_MANAGER -Imx/ODB C/Windows -I/usr/include/python2.3 -I/usr/include -c mx/ODBC /Windows/mxODBC.cpp -o build/temp.cygwin-1.5.5-i686-2.3/mx/ODBC/Windows/mxODBC/mx/ODBC/Windows/ mxODBC.o mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:593: error: storage size of `mxODBCursor_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_StringFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1115: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:1115: error: (Each undeclared identifier is reported only once for each function it appears in.) mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_UnicodeFromString(mxODBCursorObject*, mxODBCursor_Variable*)': mx/ODBC/Windows/mxODBC.cpp:1176: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_AllocateOutputVars(mxODBCursorObject*)': mx/ODBC/Windows/mxODBC.cpp:2660: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' [ ... lots more of these ...] mx/ODBC/Windows/mxODBC.cpp:2951: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:2970: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp:2981: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3002: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp:3033: error: invalid conversion from ` PyObject*(*)(mxODBCursorObject*, mxODBCursor_Variable*)' to `void*' mx/ODBC/Windows/mxODBC.cpp: In function `int mxODBCursor_BindInputParameter(mxODBCursorObject*, mxODBCursor_Variable*, PyObject*, int, int)': mx/ODBC/Windows/mxODBC.cpp:4225: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:5799: error: redefinition of `PyMethodDef mxODBCursor_Methods[]' mx/ODBC/Windows/mxODBC.cpp:593: error: ` mxODBCursor_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp:5870: error: storage size of `mxODBC_Methods' isn't known mx/ODBC/Windows/mxODBC.cpp: In function `PyObject* mxODBC_getinfo(PyObject*, PyObject*)': mx/ODBC/Windows/mxODBC.cpp:6308: error: `min' undeclared (first use this function) mx/ODBC/Windows/mxODBC.cpp: At global scope: mx/ODBC/Windows/mxODBC.cpp:6528: error: redefinition of `PyMethodDef mxODBC_Methods[]' mx/ODBC/Windows/mxODBC.cpp:5870: error: ` mxODBC_Methods' previously declared here mx/ODBC/Windows/mxODBC.cpp: In function `void initmxODBC()': mx/ODBC/Windows/mxODBC.cpp:6726: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6727: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6796: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp:6812: warning: comparison between signed and unsigned integer expressions mx/ODBC/Windows/mxODBC.cpp: At top level: mx/ODBC/Windows/mxODBC.cpp:5799: warning: `PyMethodDef mxODBCursor_Methods[26]' defined but not used mx/ODBC/Windows/mxODBC.cpp:6528: warning: `PyMethodDef mxODBC_Methods[9]' defined but not used error: command 'gcc' failed with exit status 1 I notice that sys.platform is checked for a "windows-like" value in mx/ODBC/Misc/test.py, mx/stdlib/distutils/mxSetup.py, and mxSetup.py but I'm not really able to say whether these uses need to change. Much of it seems to be about picking up the MS VC libraries, which shouldn't be relevant to mx.ODBC.Windows, I'd have thought: ./mx/ODBC/Misc/test.py 2122: if sys.platform == 'win32': ./mx/stdlib/distutils/mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1612: # Default to -py on all platforms 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) ./mxCOMMERCIAL.py 58:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 92:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': 170:if sys.platform[:3] == 'win' or sys.platform[-3:] == 'win': ./mxSetup.py 233: Only available on Windows platforms with installed compiler. 269:# are environment variables used on Windows platforms, other platforms 275:if sys.platform[:3] == 'win': 444: if sys.platform[:5] == 'win32': 1614: self.plat_name = '%s-py%s' % (get_platform(), sys.version[:3]) Does that Holden guy know what he was talking about? ;-) regards -- Steve Holden +1 703 278 8281 http://www.holdenweb.com/ Improve the Internet http://vancouver-webpages.com/CacheNow/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/