From minh at mipscomputation.com Tue Sep 2 12:43:37 2008 From: minh at mipscomputation.com (Minh-Long Pham) Date: Tue Sep 2 20:44:20 2008 Subject: [egenix-users] mxODBC doesn't support LIMIT in SELECT? Message-ID: <48BD8959.5040204@mipscomputation.com> Hi, I've connected to my database through mx.ODBC.Windows functions connect() and DriverConnect(). I was able to execute sql.execute("""SELECT count(*) FROM IM1_InventoryMasterfile""") but not sql.execute("""SELECT * FROM IM1_InventoryMasterfile LIMIT 5"""). This is the error that I get: mx.ODBC.Error.InterfaceError: ('3700', 1017, '[Best Canada][PUX ODBC Driver]Unexpected extra token: 5', 7089) Windows ODBC version: 3.525.11.32.0 Windows Python version: 2.5 Why does a simple LIMIT 5 not work? Thanks, -- Minh From mal at egenix.com Tue Sep 2 22:03:15 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Sep 2 21:03:24 2008 Subject: [egenix-users] mxODBC doesn't support LIMIT in SELECT? In-Reply-To: <48BD8959.5040204@mipscomputation.com> References: <48BD8959.5040204@mipscomputation.com> Message-ID: <48BD8DF3.3020507@egenix.com> On 2008-09-02 20:43, Minh-Long Pham wrote: > Hi, > > I've connected to my database through mx.ODBC.Windows functions > connect() and DriverConnect(). > I was able to execute sql.execute("""SELECT count(*) FROM > IM1_InventoryMasterfile""") but not > sql.execute("""SELECT * FROM IM1_InventoryMasterfile LIMIT 5"""). > > This is the error that I get: > mx.ODBC.Error.InterfaceError: ('3700', 1017, '[Best Canada][PUX ODBC > Driver]Unexpected extra token: 5', 7089) > > Windows ODBC version: 3.525.11.32.0 > Windows Python version: 2.5 > > Why does a simple LIMIT 5 not work? Whether LIMIT works or not does not depend on mxODBC. This is a feature that your database backend must provide. Which database are you using ? Does it support LIMIT ? Note that you can easily fetch just the first 5 rows from the query using cursor.fetchmany(5) This works even without LIMIT support in the database. Depending on the ODBC driver you are using, there are also other ways to further limit the number of rows that the ODBC driver fetches, e.g. using cursor.setcursoroption(SQL.ATTR_MAX_ROWS, 5) If you want to move around in the result set without actually fetching rows over the network, you can use cursor.scroll(value[,mode='relative']) However, whether this works depends on the capabilities of the ODBC driver. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 02 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From minh at mipscomputation.com Tue Sep 2 13:46:25 2008 From: minh at mipscomputation.com (Minh-Long Pham) Date: Tue Sep 2 21:47:11 2008 Subject: [egenix-users] mxODBC doesn't support LIMIT in SELECT? In-Reply-To: <48BD8DF3.3020507@egenix.com> References: <48BD8959.5040204@mipscomputation.com> <48BD8DF3.3020507@egenix.com> Message-ID: <48BD9811.6060700@mipscomputation.com> Hi, It appears if I replace "LIMIT 5" with "LIMIT:5" the error goes away. I'm pretty sure this is not the correct syntax for LIMIT, because when I fetch it takes forever just to supposedly grab 5 rows (forever as in it never takes me back to the prompt). The database I'm using is MAS90, from Sage. I'm not sure it supports LIMIT. So, yes, I've resorted to fetchmany() now. Thanks for the reply, Minh M.-A. Lemburg wrote: > On 2008-09-02 20:43, Minh-Long Pham wrote: > >> Hi, >> >> I've connected to my database through mx.ODBC.Windows functions >> connect() and DriverConnect(). >> I was able to execute sql.execute("""SELECT count(*) FROM >> IM1_InventoryMasterfile""") but not >> sql.execute("""SELECT * FROM IM1_InventoryMasterfile LIMIT 5"""). >> >> This is the error that I get: >> mx.ODBC.Error.InterfaceError: ('3700', 1017, '[Best Canada][PUX ODBC >> Driver]Unexpected extra token: 5', 7089) >> >> Windows ODBC version: 3.525.11.32.0 >> Windows Python version: 2.5 >> >> Why does a simple LIMIT 5 not work? >> > > Whether LIMIT works or not does not depend on mxODBC. This is a > feature that your database backend must provide. > > Which database are you using ? Does it support LIMIT ? > > Note that you can easily fetch just the first 5 rows from the query > using > > cursor.fetchmany(5) > > This works even without LIMIT support in the database. > > Depending on the ODBC driver you are using, there are also other > ways to further limit the number of rows that the ODBC driver > fetches, e.g. using > > cursor.setcursoroption(SQL.ATTR_MAX_ROWS, 5) > > If you want to move around in the result set without actually > fetching rows over the network, you can use > > cursor.scroll(value[,mode='relative']) > > However, whether this works depends on the capabilities of the > ODBC driver. > > From peter at fry-it.com Wed Sep 3 00:11:24 2008 From: peter at fry-it.com (Peter Bengtsson) Date: Wed Sep 3 00:11:38 2008 Subject: [egenix-users] mxODBC doesn't support LIMIT in SELECT? In-Reply-To: <48BD8959.5040204@mipscomputation.com> References: <48BD8959.5040204@mipscomputation.com> Message-ID: SQLServer uses TOP instead of LIMIT. Try TOP 5 or TOP 5,10 2008/9/2 Minh-Long Pham : > Hi, > > I've connected to my database through mx.ODBC.Windows functions > connect() and DriverConnect(). > I was able to execute sql.execute("""SELECT count(*) FROM > IM1_InventoryMasterfile""") but not > sql.execute("""SELECT * FROM IM1_InventoryMasterfile LIMIT 5"""). > > This is the error that I get: > mx.ODBC.Error.InterfaceError: ('3700', 1017, '[Best Canada][PUX ODBC > Driver]Unexpected extra token: 5', 7089) > > Windows ODBC version: 3.525.11.32.0 > Windows Python version: 2.5 > > Why does a simple LIMIT 5 not work? > > Thanks, > > -- > Minh > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > https://www.egenix.com/mailman/listinfo/egenix-users > -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com From darryljcousins at gmail.com Sat Sep 6 01:08:31 2008 From: darryljcousins at gmail.com (Darryl Cousins) Date: Fri Sep 5 14:08:38 2008 Subject: [egenix-users] [mxTidy/MacOSX] _CleanTree error Message-ID: Hi, I have struck an error on MacOS Leopard similar to this post. http://www.egenix.com/mailman-archives/egenix-users/2007-July/114231.html My error is as follows: Python 2.5.2 (r252:60911, Sep 5 2008, 23:29:08) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from mx import DateTime >>> from mx import Tidy Traceback (most recent call last): File "", line 1, in File "/Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/mx/Tidy/__init__.py", line 7, in from Tidy import * File "/Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/mx/Tidy/Tidy.py", line 7, in from mxTidy import * File "/Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/mx/Tidy/mxTidy/__init__.py", line 7, in from mxTidy import * ImportError: dlopen(/Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/mx/Tidy/mxTidy/mxTidy.so, 2): Symbol not found: _CleanTree Referenced from: /Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/mx/Tidy/mxTidy/mxTidy.so Expected in: dynamic lookup In the aforementioned post Mr Lemburg points to a fix in a future 3.0.1 version of the experimental package. Would this be the solution or is there another way I can solve the problem for myself. For further reference I've included the build output below. Kind regards, Darryl Cousins darrylcousins theshire:egenix-mx-experimental-3.0.0$ ~/Python/Python-2.5.2/bin/python2.5 setup.py install running install running build running build_clib building 'tidy' library creating build creating build/temp.macosx-10.5-i386-2.5_ucs2 creating build/temp.macosx-10.5-i386-2.5_ucs2/tidy creating build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx creating build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy creating build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy creating build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/attrs.o gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/clean.o gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/config.o gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/entities.o gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/istack.o gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/lexer.o mx/Tidy/mxTidy/libtidy/lexer.c:282: warning: 'AddStringToLexer' defined but not used gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/localize.o mx/Tidy/mxTidy/libtidy/localize.c: In function 'tidy_out': mx/Tidy/mxTidy/libtidy/localize.c:45: warning: pointer targets in assignment differ in signedness mx/Tidy/mxTidy/libtidy/localize.c:50: warning: pointer targets in passing argument 1 of 'vsnprintf' differ in signedness gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/parser.o gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/pprint.o gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/tags.o gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/tidy.o mx/Tidy/mxTidy/libtidy/tidy.c: In function 'InputStreamFromBuffer': mx/Tidy/mxTidy/libtidy/tidy.c:236: warning: pointer targets in assignment differ in signedness mx/Tidy/mxTidy/libtidy/tidy.c: In function 'OutputStreamFromBuffer': mx/Tidy/mxTidy/libtidy/tidy.c:702: warning: pointer targets in assignment differ in signedness mx/Tidy/mxTidy/libtidy/tidy.c:708: warning: pointer targets in assignment differ in signedness mx/Tidy/mxTidy/libtidy/tidy.c: In function 'WriteCharToStream': mx/Tidy/mxTidy/libtidy/tidy.c:744: warning: pointer targets in assignment differ in signedness mx/Tidy/mxTidy/libtidy/tidy.c:750: warning: pointer targets in assignment differ in signedness mx/Tidy/mxTidy/libtidy/tidy.c: In function 'WriteStringToStream': mx/Tidy/mxTidy/libtidy/tidy.c:766: warning: pointer targets in assignment differ in signedness mx/Tidy/mxTidy/libtidy/tidy.c:773: warning: pointer targets in assignment differ in signedness ar -cr build/temp.macosx-10.5-i386-2.5_ucs2/libtidy.a build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/attrs.o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/clean.o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/config.o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/entities.o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/istack.o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/lexer.o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/localize.o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/parser.o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/pprint.o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/tags.o build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/tidy.o ranlib build/temp.macosx-10.5-i386-2.5_ucs2/libtidy.a running mx_autoconf gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/opt/local/include -I/Users/darrylcousins/Python/Python-2.5.2/include -c _configtest.c -o _configtest.o _configtest.c: In function 'main': _configtest.c:4: warning: statement with no effect gcc -I/opt/local/include -L/opt/local/lib _configtest.o -L/opt/local/lib -L/Users/darrylcousins/Python/Python-2.5.2/lib -o _configtest success! removing: _configtest.c _configtest.o _configtest gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/Users/darrylcousins/Python/Python-2.5.2/include/python2.5 -I/opt/local/include -I/Users/darrylcousins/Python/Python-2.5.2/include -c _configtest.c -o _configtest.o success! removing: _configtest.c _configtest.o macros to define: [('HAVE_STRPTIME', '1')] macros to undefine: [] running build_ext building extension "mx.Tidy.mxTidy.mxTidy" (required) building 'mx.Tidy.mxTidy.mxTidy' extension creating build/temp.macosx-10.5-i386-2.5_ucs2/mx-Tidy-mxTidy-mxTidy creating build/temp.macosx-10.5-i386-2.5_ucs2/mx-Tidy-mxTidy-mxTidy/mx creating build/temp.macosx-10.5-i386-2.5_ucs2/mx-Tidy-mxTidy-mxTidy/mx/Tidy creating build/temp.macosx-10.5-i386-2.5_ucs2/mx-Tidy-mxTidy-mxTidy/mx/Tidy/mxTidy gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -DHAVE_STRPTIME=1 -Imx/Tidy/mxTidy -Imx/Tidy/mxTidy/libtidy -I/Users/darrylcousins/Python/Python-2.5.2/include/python2.5 -I/opt/local/include -I/Users/darrylcousins/Python/Python-2.5.2/include -c mx/Tidy/mxTidy/mxTidy.c -o build/temp.macosx-10.5-i386-2.5_ucs2/mx-Tidy-mxTidy-mxTidy/mx/Tidy/mxTidy/mxTidy.o creating build/lib.macosx-10.5-i386-2.5_ucs2 creating build/lib.macosx-10.5-i386-2.5_ucs2/mx creating build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy creating build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy gcc -I/opt/local/include -L/opt/local/lib -bundle -undefined dynamic_lookup build/temp.macosx-10.5-i386-2.5_ucs2/mx-Tidy-mxTidy-mxTidy/mx/Tidy/mxTidy/mxTidy.o -Lmx/Tidy/mxTidy/libtidy -Lbuild/temp.macosx-10.5-i386-2.5_ucs2 -L/opt/local/lib -L/Users/darrylcousins/Python/Python-2.5.2/lib -ltidy -ltidy -o build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy/mxTidy.so building extension "mx.Number.mxNumber.mxNumber" (optional) looking for header files needed by extension "mx.Number.mxNumber.mxNumber" *** WARNING: Building of extension "mx.Number.mxNumber.mxNumber" failed: needed include file "gmp.h" not found running build_py copying mx/__init__.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx creating build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number copying mx/Number/__init__.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number copying mx/Number/LazyModule.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number copying mx/Number/Number.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number creating build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number/mxNumber copying mx/Number/mxNumber/__init__.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number/mxNumber copying mx/Number/mxNumber/test.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number/mxNumber copying mx/Tidy/__init__.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy copying mx/Tidy/Tidy.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy copying mx/Tidy/mxTidy/__init__.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/test.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testMadjakarta.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testMateusz.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy copying mx/Tidy/mxTidy/testWalter.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy running install_lib copying build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy/mxTidy.so -> /Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/mx/Tidy/mxTidy writing byte-compilation script '/var/folders/rV/rVAGWhmsHWSmKVQIPwGHhk+++TI/-Tmp-/tmpSQ9KQN.py' /Users/darrylcousins/Python/Python-2.5.2/bin/python2.5 -O /var/folders/rV/rVAGWhmsHWSmKVQIPwGHhk+++TI/-Tmp-/tmpSQ9KQN.py removing /var/folders/rV/rVAGWhmsHWSmKVQIPwGHhk+++TI/-Tmp-/tmpSQ9KQN.py running install_data running install_egg_info Removing /Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/egenix_mx_experimental-3.0.0-py2.5.egg-info Writing /Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/egenix_mx_experimental-3.0.0-py2.5.egg-info From mal at egenix.com Fri Sep 5 15:31:52 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Sep 5 14:31:57 2008 Subject: [egenix-users] [mxTidy/MacOSX] _CleanTree error In-Reply-To: References: Message-ID: <48C126B8.8060505@egenix.com> On 2008-09-05 14:08, Darryl Cousins wrote: > Hi, > > I have struck an error on MacOS Leopard similar to this post. > > http://www.egenix.com/mailman-archives/egenix-users/2007-July/114231.html > > My error is as follows: > > Python 2.5.2 (r252:60911, Sep 5 2008, 23:29:08) > [GCC 4.0.1 (Apple Inc. build 5465)] on darwin > Type "help", "copyright", "credits" or "license" for more information. >>>> from mx import DateTime >>>> from mx import Tidy > Traceback (most recent call last): > File "", line 1, in > File "/Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/mx/Tidy/__init__.py", > line 7, in > from Tidy import * > File "/Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/mx/Tidy/Tidy.py", > line 7, in > from mxTidy import * > File "/Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/mx/Tidy/mxTidy/__init__.py", > line 7, in > from mxTidy import * > ImportError: dlopen(/Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/mx/Tidy/mxTidy/mxTidy.so, > 2): Symbol not found: _CleanTree > Referenced from: > /Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/mx/Tidy/mxTidy/mxTidy.so > Expected in: dynamic lookup > > In the aforementioned post Mr Lemburg points to a fix in a future > 3.0.1 version of the experimental package. Would this be the solution > or is there another way I can solve the problem for myself. We should really ship a new version of the experimental package. It's mainly lack of time that's keeping us from doing so. Anyway, here's a snapshot which will likely solve your problem: http://downloads.egenix.com/python/egenix-mx-experimental-3.1.0_dev_20080905.zip It also includes a new package called "mxIP" which allows IP-based country geo-location. No documentation yet unfortunately, but the source code should have enough hints to get you going. It uses the geo location databases of Webnet77 or MaxMind. > For further reference I've included the build output below. > > Kind regards, > Darryl Cousins > > darrylcousins theshire:egenix-mx-experimental-3.0.0$ > ~/Python/Python-2.5.2/bin/python2.5 setup.py install > running install > running build > running build_clib > building 'tidy' library > creating build > creating build/temp.macosx-10.5-i386-2.5_ucs2 > creating build/temp.macosx-10.5-i386-2.5_ucs2/tidy > creating build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx > creating build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy > creating build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy > creating build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy > gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing > -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv > -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 > -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/attrs.o > gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing > -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv > -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 > -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/clean.o > gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing > -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv > -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 > -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/config.o > gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing > -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv > -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 > -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/entities.o > gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing > -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv > -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 > -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/istack.o > gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing > -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv > -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 > -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/lexer.o > mx/Tidy/mxTidy/libtidy/lexer.c:282: warning: 'AddStringToLexer' > defined but not used > gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing > -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv > -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 > -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/localize.o > mx/Tidy/mxTidy/libtidy/localize.c: In function 'tidy_out': > mx/Tidy/mxTidy/libtidy/localize.c:45: warning: pointer targets in > assignment differ in signedness > mx/Tidy/mxTidy/libtidy/localize.c:50: warning: pointer targets in > passing argument 1 of 'vsnprintf' differ in signedness > gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing > -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv > -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 > -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/parser.o > gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing > -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv > -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 > -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/pprint.o > gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing > -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv > -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 > -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/tags.o > gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing > -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv > -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 > -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/tidy.o > mx/Tidy/mxTidy/libtidy/tidy.c: In function 'InputStreamFromBuffer': > mx/Tidy/mxTidy/libtidy/tidy.c:236: warning: pointer targets in > assignment differ in signedness > mx/Tidy/mxTidy/libtidy/tidy.c: In function 'OutputStreamFromBuffer': > mx/Tidy/mxTidy/libtidy/tidy.c:702: warning: pointer targets in > assignment differ in signedness > mx/Tidy/mxTidy/libtidy/tidy.c:708: warning: pointer targets in > assignment differ in signedness > mx/Tidy/mxTidy/libtidy/tidy.c: In function 'WriteCharToStream': > mx/Tidy/mxTidy/libtidy/tidy.c:744: warning: pointer targets in > assignment differ in signedness > mx/Tidy/mxTidy/libtidy/tidy.c:750: warning: pointer targets in > assignment differ in signedness > mx/Tidy/mxTidy/libtidy/tidy.c: In function 'WriteStringToStream': > mx/Tidy/mxTidy/libtidy/tidy.c:766: warning: pointer targets in > assignment differ in signedness > mx/Tidy/mxTidy/libtidy/tidy.c:773: warning: pointer targets in > assignment differ in signedness > ar -cr build/temp.macosx-10.5-i386-2.5_ucs2/libtidy.a > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/attrs.o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/clean.o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/config.o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/entities.o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/istack.o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/lexer.o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/localize.o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/parser.o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/pprint.o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/tags.o > build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/tidy.o > ranlib build/temp.macosx-10.5-i386-2.5_ucs2/libtidy.a > running mx_autoconf > gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing > -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv > -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/opt/local/include > -I/Users/darrylcousins/Python/Python-2.5.2/include -c _configtest.c -o > _configtest.o > _configtest.c: In function 'main': > _configtest.c:4: warning: statement with no effect > gcc -I/opt/local/include -L/opt/local/lib _configtest.o > -L/opt/local/lib -L/Users/darrylcousins/Python/Python-2.5.2/lib -o > _configtest > success! > removing: _configtest.c _configtest.o _configtest > gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing > -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv > -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 > -I/Users/darrylcousins/Python/Python-2.5.2/include/python2.5 > -I/opt/local/include > -I/Users/darrylcousins/Python/Python-2.5.2/include -c _configtest.c -o > _configtest.o > success! > removing: _configtest.c _configtest.o > macros to define: [('HAVE_STRPTIME', '1')] > macros to undefine: [] > running build_ext > > building extension "mx.Tidy.mxTidy.mxTidy" (required) > building 'mx.Tidy.mxTidy.mxTidy' extension > creating build/temp.macosx-10.5-i386-2.5_ucs2/mx-Tidy-mxTidy-mxTidy > creating build/temp.macosx-10.5-i386-2.5_ucs2/mx-Tidy-mxTidy-mxTidy/mx > creating build/temp.macosx-10.5-i386-2.5_ucs2/mx-Tidy-mxTidy-mxTidy/mx/Tidy > creating build/temp.macosx-10.5-i386-2.5_ucs2/mx-Tidy-mxTidy-mxTidy/mx/Tidy/mxTidy > gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing > -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv > -O3 -Wall -Wstrict-prototypes -DHAVE_STRPTIME=1 -Imx/Tidy/mxTidy > -Imx/Tidy/mxTidy/libtidy > -I/Users/darrylcousins/Python/Python-2.5.2/include/python2.5 > -I/opt/local/include > -I/Users/darrylcousins/Python/Python-2.5.2/include -c > mx/Tidy/mxTidy/mxTidy.c -o > build/temp.macosx-10.5-i386-2.5_ucs2/mx-Tidy-mxTidy-mxTidy/mx/Tidy/mxTidy/mxTidy.o > creating build/lib.macosx-10.5-i386-2.5_ucs2 > creating build/lib.macosx-10.5-i386-2.5_ucs2/mx > creating build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy > creating build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy > gcc -I/opt/local/include -L/opt/local/lib -bundle -undefined > dynamic_lookup build/temp.macosx-10.5-i386-2.5_ucs2/mx-Tidy-mxTidy-mxTidy/mx/Tidy/mxTidy/mxTidy.o > -Lmx/Tidy/mxTidy/libtidy -Lbuild/temp.macosx-10.5-i386-2.5_ucs2 > -L/opt/local/lib -L/Users/darrylcousins/Python/Python-2.5.2/lib -ltidy > -ltidy -o build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy/mxTidy.so > > building extension "mx.Number.mxNumber.mxNumber" (optional) > looking for header files needed by extension "mx.Number.mxNumber.mxNumber" > *** WARNING: Building of extension "mx.Number.mxNumber.mxNumber" > failed: needed include file "gmp.h" not found > > running build_py > copying mx/__init__.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx > creating build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number > copying mx/Number/__init__.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number > copying mx/Number/LazyModule.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number > copying mx/Number/Number.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number > creating build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number/mxNumber > copying mx/Number/mxNumber/__init__.py -> > build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number/mxNumber > copying mx/Number/mxNumber/test.py -> > build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number/mxNumber > copying mx/Tidy/__init__.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy > copying mx/Tidy/Tidy.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy > copying mx/Tidy/mxTidy/__init__.py -> > build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy > copying mx/Tidy/mxTidy/test.py -> > build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy > copying mx/Tidy/mxTidy/testMadjakarta.py -> > build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy > copying mx/Tidy/mxTidy/testMateusz.py -> > build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy > copying mx/Tidy/mxTidy/testWalter.py -> > build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy > running install_lib > copying build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy/mxTidy.so > -> /Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/mx/Tidy/mxTidy > writing byte-compilation script > '/var/folders/rV/rVAGWhmsHWSmKVQIPwGHhk+++TI/-Tmp-/tmpSQ9KQN.py' > /Users/darrylcousins/Python/Python-2.5.2/bin/python2.5 -O > /var/folders/rV/rVAGWhmsHWSmKVQIPwGHhk+++TI/-Tmp-/tmpSQ9KQN.py > removing /var/folders/rV/rVAGWhmsHWSmKVQIPwGHhk+++TI/-Tmp-/tmpSQ9KQN.py > running install_data > running install_egg_info > Removing /Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/egenix_mx_experimental-3.0.0-py2.5.egg-info > Writing /Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/egenix_mx_experimental-3.0.0-py2.5.egg-info > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > https://www.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 05 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From darryljcousins at gmail.com Sat Sep 6 09:31:42 2008 From: darryljcousins at gmail.com (Darryl Cousins) Date: Fri Sep 5 22:43:12 2008 Subject: [egenix-users] [mxTidy/MacOSX] _CleanTree error In-Reply-To: <48C126B8.8060505@egenix.com> References: <48C126B8.8060505@egenix.com> Message-ID: On Sat, Sep 6, 2008 at 12:31 AM, M.-A. Lemburg wrote: > On 2008-09-05 14:08, Darryl Cousins wrote: >> Hi, >> >> I have struck an error on MacOS Leopard similar to this post. >> >> http://www.egenix.com/mailman-archives/egenix-users/2007-July/114231.html >> >> My error is as follows: >> >> Python 2.5.2 (r252:60911, Sep 5 2008, 23:29:08) >> [GCC 4.0.1 (Apple Inc. build 5465)] on darwin >> Type "help", "copyright", "credits" or "license" for more information. >>>>> from mx import DateTime >>>>> from mx import Tidy >> Traceback (most recent call last): >> File "", line 1, in >> File "/Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/mx/Tidy/__init__.py", >> line 7, in >> from Tidy import * >> File "/Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/mx/Tidy/Tidy.py", >> line 7, in >> from mxTidy import * >> File "/Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/mx/Tidy/mxTidy/__init__.py", >> line 7, in >> from mxTidy import * >> ImportError: dlopen(/Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/mx/Tidy/mxTidy/mxTidy.so, >> 2): Symbol not found: _CleanTree >> Referenced from: >> /Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/mx/Tidy/mxTidy/mxTidy.so >> Expected in: dynamic lookup >> >> In the aforementioned post Mr Lemburg points to a fix in a future >> 3.0.1 version of the experimental package. Would this be the solution >> or is there another way I can solve the problem for myself. > > We should really ship a new version of the experimental package. > It's mainly lack of time that's keeping us from doing so. > > Anyway, here's a snapshot which will likely solve your problem: > > http://downloads.egenix.com/python/egenix-mx-experimental-3.1.0_dev_20080905.zip > > It also includes a new package called "mxIP" which allows IP-based > country geo-location. No documentation yet unfortunately, but the > source code should have enough hints to get you going. It uses the > geo location databases of Webnet77 or MaxMind. Hi, Thanks very much for the snapshot package. Yes indeed that has got me up and running. Mit freundlichen Gruessen, Darryl Cousins >> For further reference I've included the build output below. >> >> Kind regards, >> Darryl Cousins >> >> darrylcousins theshire:egenix-mx-experimental-3.0.0$ >> ~/Python/Python-2.5.2/bin/python2.5 setup.py install >> running install >> running build >> running build_clib >> building 'tidy' library >> creating build >> creating build/temp.macosx-10.5-i386-2.5_ucs2 >> creating build/temp.macosx-10.5-i386-2.5_ucs2/tidy >> creating build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx >> creating build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy >> creating build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy >> creating build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy >> gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing >> -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv >> -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 >> -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/attrs.c -o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/attrs.o >> gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing >> -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv >> -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 >> -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/clean.c -o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/clean.o >> gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing >> -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv >> -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 >> -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/config.c -o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/config.o >> gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing >> -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv >> -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 >> -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/entities.c -o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/entities.o >> gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing >> -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv >> -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 >> -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/istack.c -o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/istack.o >> gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing >> -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv >> -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 >> -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/lexer.c -o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/lexer.o >> mx/Tidy/mxTidy/libtidy/lexer.c:282: warning: 'AddStringToLexer' >> defined but not used >> gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing >> -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv >> -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 >> -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/localize.c -o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/localize.o >> mx/Tidy/mxTidy/libtidy/localize.c: In function 'tidy_out': >> mx/Tidy/mxTidy/libtidy/localize.c:45: warning: pointer targets in >> assignment differ in signedness >> mx/Tidy/mxTidy/libtidy/localize.c:50: warning: pointer targets in >> passing argument 1 of 'vsnprintf' differ in signedness >> gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing >> -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv >> -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 >> -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/parser.c -o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/parser.o >> gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing >> -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv >> -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 >> -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/pprint.c -o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/pprint.o >> gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing >> -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv >> -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 >> -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tags.c -o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/tags.o >> gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing >> -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv >> -O3 -Wall -Wstrict-prototypes -DCOMPILING_TIDY=1 >> -Imx/Tidy/mxTidy/libtidy -c mx/Tidy/mxTidy/libtidy/tidy.c -o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/tidy.o >> mx/Tidy/mxTidy/libtidy/tidy.c: In function 'InputStreamFromBuffer': >> mx/Tidy/mxTidy/libtidy/tidy.c:236: warning: pointer targets in >> assignment differ in signedness >> mx/Tidy/mxTidy/libtidy/tidy.c: In function 'OutputStreamFromBuffer': >> mx/Tidy/mxTidy/libtidy/tidy.c:702: warning: pointer targets in >> assignment differ in signedness >> mx/Tidy/mxTidy/libtidy/tidy.c:708: warning: pointer targets in >> assignment differ in signedness >> mx/Tidy/mxTidy/libtidy/tidy.c: In function 'WriteCharToStream': >> mx/Tidy/mxTidy/libtidy/tidy.c:744: warning: pointer targets in >> assignment differ in signedness >> mx/Tidy/mxTidy/libtidy/tidy.c:750: warning: pointer targets in >> assignment differ in signedness >> mx/Tidy/mxTidy/libtidy/tidy.c: In function 'WriteStringToStream': >> mx/Tidy/mxTidy/libtidy/tidy.c:766: warning: pointer targets in >> assignment differ in signedness >> mx/Tidy/mxTidy/libtidy/tidy.c:773: warning: pointer targets in >> assignment differ in signedness >> ar -cr build/temp.macosx-10.5-i386-2.5_ucs2/libtidy.a >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/attrs.o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/clean.o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/config.o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/entities.o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/istack.o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/lexer.o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/localize.o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/parser.o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/pprint.o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/tags.o >> build/temp.macosx-10.5-i386-2.5_ucs2/tidy/mx/Tidy/mxTidy/libtidy/tidy.o >> ranlib build/temp.macosx-10.5-i386-2.5_ucs2/libtidy.a >> running mx_autoconf >> gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing >> -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv >> -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 -I/opt/local/include >> -I/Users/darrylcousins/Python/Python-2.5.2/include -c _configtest.c -o >> _configtest.o >> _configtest.c: In function 'main': >> _configtest.c:4: warning: statement with no effect >> gcc -I/opt/local/include -L/opt/local/lib _configtest.o >> -L/opt/local/lib -L/Users/darrylcousins/Python/Python-2.5.2/lib -o >> _configtest >> success! >> removing: _configtest.c _configtest.o _configtest >> gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing >> -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv >> -O3 -Wall -Wstrict-prototypes -D_GNU_SOURCE=1 >> -I/Users/darrylcousins/Python/Python-2.5.2/include/python2.5 >> -I/opt/local/include >> -I/Users/darrylcousins/Python/Python-2.5.2/include -c _configtest.c -o >> _configtest.o >> success! >> removing: _configtest.c _configtest.o >> macros to define: [('HAVE_STRPTIME', '1')] >> macros to undefine: [] >> running build_ext >> >> building extension "mx.Tidy.mxTidy.mxTidy" (required) >> building 'mx.Tidy.mxTidy.mxTidy' extension >> creating build/temp.macosx-10.5-i386-2.5_ucs2/mx-Tidy-mxTidy-mxTidy >> creating build/temp.macosx-10.5-i386-2.5_ucs2/mx-Tidy-mxTidy-mxTidy/mx >> creating build/temp.macosx-10.5-i386-2.5_ucs2/mx-Tidy-mxTidy-mxTidy/mx/Tidy >> creating build/temp.macosx-10.5-i386-2.5_ucs2/mx-Tidy-mxTidy-mxTidy/mx/Tidy/mxTidy >> gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing >> -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -fwrapv >> -O3 -Wall -Wstrict-prototypes -DHAVE_STRPTIME=1 -Imx/Tidy/mxTidy >> -Imx/Tidy/mxTidy/libtidy >> -I/Users/darrylcousins/Python/Python-2.5.2/include/python2.5 >> -I/opt/local/include >> -I/Users/darrylcousins/Python/Python-2.5.2/include -c >> mx/Tidy/mxTidy/mxTidy.c -o >> build/temp.macosx-10.5-i386-2.5_ucs2/mx-Tidy-mxTidy-mxTidy/mx/Tidy/mxTidy/mxTidy.o >> creating build/lib.macosx-10.5-i386-2.5_ucs2 >> creating build/lib.macosx-10.5-i386-2.5_ucs2/mx >> creating build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy >> creating build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy >> gcc -I/opt/local/include -L/opt/local/lib -bundle -undefined >> dynamic_lookup build/temp.macosx-10.5-i386-2.5_ucs2/mx-Tidy-mxTidy-mxTidy/mx/Tidy/mxTidy/mxTidy.o >> -Lmx/Tidy/mxTidy/libtidy -Lbuild/temp.macosx-10.5-i386-2.5_ucs2 >> -L/opt/local/lib -L/Users/darrylcousins/Python/Python-2.5.2/lib -ltidy >> -ltidy -o build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy/mxTidy.so >> >> building extension "mx.Number.mxNumber.mxNumber" (optional) >> looking for header files needed by extension "mx.Number.mxNumber.mxNumber" >> *** WARNING: Building of extension "mx.Number.mxNumber.mxNumber" >> failed: needed include file "gmp.h" not found >> >> running build_py >> copying mx/__init__.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx >> creating build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number >> copying mx/Number/__init__.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number >> copying mx/Number/LazyModule.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number >> copying mx/Number/Number.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number >> creating build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number/mxNumber >> copying mx/Number/mxNumber/__init__.py -> >> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number/mxNumber >> copying mx/Number/mxNumber/test.py -> >> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Number/mxNumber >> copying mx/Tidy/__init__.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy >> copying mx/Tidy/Tidy.py -> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy >> copying mx/Tidy/mxTidy/__init__.py -> >> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy >> copying mx/Tidy/mxTidy/test.py -> >> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy >> copying mx/Tidy/mxTidy/testMadjakarta.py -> >> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy >> copying mx/Tidy/mxTidy/testMateusz.py -> >> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy >> copying mx/Tidy/mxTidy/testWalter.py -> >> build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy >> running install_lib >> copying build/lib.macosx-10.5-i386-2.5_ucs2/mx/Tidy/mxTidy/mxTidy.so >> -> /Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/mx/Tidy/mxTidy >> writing byte-compilation script >> '/var/folders/rV/rVAGWhmsHWSmKVQIPwGHhk+++TI/-Tmp-/tmpSQ9KQN.py' >> /Users/darrylcousins/Python/Python-2.5.2/bin/python2.5 -O >> /var/folders/rV/rVAGWhmsHWSmKVQIPwGHhk+++TI/-Tmp-/tmpSQ9KQN.py >> removing /var/folders/rV/rVAGWhmsHWSmKVQIPwGHhk+++TI/-Tmp-/tmpSQ9KQN.py >> running install_data >> running install_egg_info >> Removing /Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/egenix_mx_experimental-3.0.0-py2.5.egg-info >> Writing /Users/darrylcousins/Python/Python-2.5.2/lib/python2.5/site-packages/egenix_mx_experimental-3.0.0-py2.5.egg-info >> >> >> _______________________________________________________________________ >> eGenix.com User Mailing List http://www.egenix.com/ >> https://www.egenix.com/mailman/listinfo/egenix-users > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, Sep 05 2008) >>>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > > :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: > > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > From ballen at zeomega.com Tue Sep 9 22:18:55 2008 From: ballen at zeomega.com (Brad Allen) Date: Wed Sep 10 04:19:04 2008 Subject: [egenix-users] cursor.executedirect configurable? Message-ID: <48C72E8F.3090109@zeomega.com> Hello, I am using mxODBC 3 with the Storm ORM, which makes use of cursor.execute. I would like to find a way to configure mxODBC to use executedirect without having to change or override Storm's call to cursor.execute. Is there some way to configure mxODBC to use the executedirect behavior when cursor.execute is called? Thanks. -- ZeOmega Open Minds' Open Solutions 3010 Gaylord Parkway, Ste. 210 Frisco TX, 75034 http://www.zeomega.com Brad Allen 214-618-9880 (ext. 8006) From mal at egenix.com Wed Sep 10 12:13:15 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Sep 10 11:13:33 2008 Subject: [egenix-users] cursor.executedirect configurable? In-Reply-To: <48C72E8F.3090109@zeomega.com> References: <48C72E8F.3090109@zeomega.com> Message-ID: <48C78FAB.6010002@egenix.com> Hello Brad, On 2008-09-10 04:18, Brad Allen wrote: > I am using mxODBC 3 with the Storm ORM, which makes use of > cursor.execute. I would like to find a way to configure mxODBC to use > executedirect without having to change or override Storm's call to > cursor.execute. > > Is there some way to configure mxODBC to use the executedirect behavior > when cursor.execute is called? No, that's not possible without wrapping the cursor object and then redirecting the method in the wrapper. Note that cursor.execute() will work like cursor.executedirect() when called without parameters. You should check the performance of using one over the other. cursor.executedirect() will bypass the prepare step, so the statement will have to be parsed and processed over and over again. Some database backends do clever caching on the server, so this is not an issue, in fact, it's faster for simple queries since you avoid a few network round-trips. For other backends, it's slower, since they don't implement such caching. Another issue is related to parameter binding: using cursor.executedirect() the ODBC driver does not have any parameter type information available (this only becomes available via the prepare step), so mxODBC cannot do any efficient conversion to database data types on the client side. This may result in conversion problems on the server side and introduce extra overhead. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 10 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From ballen at zeomega.com Wed Sep 10 09:48:16 2008 From: ballen at zeomega.com (Brad Allen) Date: Wed Sep 10 15:48:30 2008 Subject: [egenix-users] cursor.executedirect configurable? In-Reply-To: <48C78FAB.6010002@egenix.com> References: <48C72E8F.3090109@zeomega.com> <48C78FAB.6010002@egenix.com> Message-ID: <48C7D020.4030908@zeomega.com> Thanks. I haven't yet done any serious performance comparisons between execute and executedirect with the ODBC driver we're using ( the built-in Windows ODBC driver for SQL Server). Instead, I was motivated by the finding that some of the large join queries I generated using Storm worked with executedirect, but failed cryptically using plain cursor.execute. I would prefer to find out why the same query failed with cursor.execute rather than switch to executedirect. Any ideas on what would cause this a select query to fail with the plain execute, but works fine with executedirect? Here is the error: mx.ODBC.Error.InterfaceError: ('07009', 0, '[Microsoft][ODBC SQL Server Driver]Invalid Descriptor Index', 6793) Thanks. M.-A. Lemburg wrote: > Hello Brad, > > On 2008-09-10 04:18, Brad Allen wrote: > >> I am using mxODBC 3 with the Storm ORM, which makes use of >> cursor.execute. I would like to find a way to configure mxODBC to use >> executedirect without having to change or override Storm's call to >> cursor.execute. >> >> Is there some way to configure mxODBC to use the executedirect behavior >> when cursor.execute is called? >> > > No, that's not possible without wrapping the cursor object and > then redirecting the method in the wrapper. > > Note that cursor.execute() will work like cursor.executedirect() > when called without parameters. > > You should check the performance of using one over the other. > cursor.executedirect() will bypass the prepare step, so the > statement will have to be parsed and processed over and over > again. > > Some database backends do clever caching on the server, so this > is not an issue, in fact, it's faster for simple queries since > you avoid a few network round-trips. > > For other backends, it's slower, since they don't implement > such caching. > > Another issue is related to parameter binding: using > cursor.executedirect() the ODBC driver does not have any > parameter type information available (this only becomes > available via the prepare step), so mxODBC cannot do > any efficient conversion to database data types on the > client side. This may result in conversion problems on > the server side and introduce extra overhead. > > -- ZeOmega Open Minds' Open Solutions 3010 Gaylord Parkway, Ste. 210 Frisco TX, 75034 http://www.zeomega.com Brad Allen 214-618-9880 (ext. 8006) -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20080910/1a67c691/attachment.htm From mal at egenix.com Wed Sep 10 18:23:17 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Sep 10 17:23:25 2008 Subject: [egenix-users] cursor.executedirect configurable? In-Reply-To: <48C7D020.4030908@zeomega.com> References: <48C72E8F.3090109@zeomega.com> <48C78FAB.6010002@egenix.com> <48C7D020.4030908@zeomega.com> Message-ID: <48C7E665.7000803@egenix.com> On 2008-09-10 15:48, Brad Allen wrote: > Thanks. I haven't yet done any serious performance comparisons between > execute and executedirect with the ODBC driver we're using ( the > built-in Windows ODBC driver for SQL Server). > > Instead, I was motivated by the finding that some of the large join > queries I generated using Storm worked with executedirect, but failed > cryptically using plain cursor.execute. I would prefer to find out why > the same query failed with cursor.execute rather than switch to > executedirect. > > Any ideas on what would cause this a select query to fail with the plain > execute, but works fine with executedirect? The plain .execute() uses a prepare step, SQL type binding and does some processing directly on the client, whereas .executedirect() sends all data to the server for processing and uses Python type binding for parameters. > Here is the error: > > mx.ODBC.Error.InterfaceError: ('07009', 0, '[Microsoft][ODBC SQL Server > Driver]Invalid Descriptor Index', 6793) Could also post the query and parameters that caused this problem ? The error is related to a parameter you have in the query which the client apparently does not detect correctly. Thanks. > Thanks. > > M.-A. Lemburg wrote: >> Hello Brad, >> >> On 2008-09-10 04:18, Brad Allen wrote: >> >>> I am using mxODBC 3 with the Storm ORM, which makes use of >>> cursor.execute. I would like to find a way to configure mxODBC to use >>> executedirect without having to change or override Storm's call to >>> cursor.execute. >>> >>> Is there some way to configure mxODBC to use the executedirect behavior >>> when cursor.execute is called? >>> >> >> No, that's not possible without wrapping the cursor object and >> then redirecting the method in the wrapper. >> >> Note that cursor.execute() will work like cursor.executedirect() >> when called without parameters. >> >> You should check the performance of using one over the other. >> cursor.executedirect() will bypass the prepare step, so the >> statement will have to be parsed and processed over and over >> again. >> >> Some database backends do clever caching on the server, so this >> is not an issue, in fact, it's faster for simple queries since >> you avoid a few network round-trips. >> >> For other backends, it's slower, since they don't implement >> such caching. >> >> Another issue is related to parameter binding: using >> cursor.executedirect() the ODBC driver does not have any >> parameter type information available (this only becomes >> available via the prepare step), so mxODBC cannot do >> any efficient conversion to database data types on the >> client side. This may result in conversion problems on >> the server side and introduce extra overhead. >> >> > > > ------------------------------------------------------------------------ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > https://www.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 10 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From mal at egenix.com Thu Sep 11 13:08:37 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Sep 11 12:08:41 2008 Subject: [egenix-users] cursor.executedirect configurable? In-Reply-To: <48C824BB.5080303@zeomega.com> References: <48C72E8F.3090109@zeomega.com> <48C78FAB.6010002@egenix.com> <48C7D020.4030908@zeomega.com> <48C7E665.7000803@egenix.com> <48C824BB.5080303@zeomega.com> Message-ID: <48C8EE25.1000704@egenix.com> On 2008-09-10 21:49, Brad Allen wrote: > M.-A. Lemburg wrote: >> >>> Here is the error: >>> >>> mx.ODBC.Error.InterfaceError: ('07009', 0, '[Microsoft][ODBC SQL Server >>> Driver]Invalid Descriptor Index', 6793) >> >> Could also post the query and parameters that caused this problem ? >> >> The error is related to a parameter you have in the query which >> the client apparently does not detect correctly. > > The query is a bit ugly; it is generated by Storm and the table aliases > are numeric, not designed to be human readable. Also, I copied it > straight from the DOS prompt. If you need to really read and fully > understand the query, I can send an alternate human readable version. > > The parameters are all plain ascii strings. We have configured mxODBC to > use MIXED_STRINGFORMAT and PYDATETIME_DATETIMEFORMAT. > > > See the pdb transcript below, showing first the statement, and after > that the parameters. > > (Pdb) statement > ... long query better not shown in public ;-) ... > > (Pdb) params > [, > ariable object at 0x0161C3B0>, 0x0161C > 490>, , > wStrVariable object at 0x0161C590>, object at 0x > 0161C5F0>, , > es.RawStrVariable object at 0x0161C6F0>] > > (Pdb) for param in params: print param.get() > Y > X > X > Y > X > Y > X > Y You have 8 '?' markers in your query, so that looks fine. However, the query is rather complicated with respect to all the joins, so it's possible that the ODBC driver doesn't parse the query correctly and perhaps misses out on some of the parameter markers. It may also get confused by the "_3" aliases. Why the quotes and why double-quotes instead of square brackets ?. What setting do you use for QUOTED_IDENTIFIERS ? Some more general questions: Are you using the most recent SQL Server Native client on the Windows machine ? How are you converting the params before using them on cursor.execute() ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 11 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From ballen at zeomega.com Thu Sep 11 11:28:51 2008 From: ballen at zeomega.com (Brad Allen) Date: Thu Sep 11 17:29:00 2008 Subject: [egenix-users] cursor.executedirect configurable? In-Reply-To: <48C8EE25.1000704@egenix.com> References: <48C72E8F.3090109@zeomega.com> <48C78FAB.6010002@egenix.com> <48C7D020.4030908@zeomega.com> <48C7E665.7000803@egenix.com> <48C824BB.5080303@zeomega.com> <48C8EE25.1000704@egenix.com> Message-ID: <48C93933.8000708@zeomega.com> M.-A. Lemburg wrote: > > You have 8 '?' markers in your query, so that looks fine. However, > the query is rather complicated with respect to all the joins, so > it's possible that the ODBC driver doesn't parse the query correctly > and perhaps misses out on some of the parameter markers. > > It may also get confused by the "_3" aliases. Why the quotes and why > double-quotes instead of square brackets ?. What setting do you > use for QUOTED_IDENTIFIERS ? > I those "_3" aliases were created by Storm's ClassAlias; I discovered a parameter that would allow me to specify the name when creating the ClassAlias instances. That got rid of the "_3" aliases in the query, and there are no more quoted identifiers, and now the query is more readable. However, it still fails when using cursor.execute and succeeds when using cursor.executedirect. > Some more general questions: > > Are you using the most recent SQL Server Native client on the > Windows machine ? > I was using the normal SQL Server driver; I changed to the SQL Server native client but am still seeing the same behavior. As far as whether it's the latest, it's the version that comes with Windows Server 2003 Standard Edition Service Pack 3. > How are you converting the params before using them on > cursor.execute() ? > > I think Storm is handling that by building a tuple of a tuple of strings, just like we would normally pass to cursor.execute for bind parameters. I haven't checked to see exactly what it is doing there, but we aren't having any issues with parameter substitution for any of our other queries. -- ZeOmega Open Minds' Open Solutions 3010 Gaylord Parkway, Ste. 210 Frisco TX, 75034 http://www.zeomega.com Brad Allen 214-618-9880 (ext. 8006) From mal at egenix.com Thu Sep 11 20:44:51 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Sep 11 19:44:56 2008 Subject: [egenix-users] cursor.executedirect configurable? In-Reply-To: <48C93933.8000708@zeomega.com> References: <48C72E8F.3090109@zeomega.com> <48C78FAB.6010002@egenix.com> <48C7D020.4030908@zeomega.com> <48C7E665.7000803@egenix.com> <48C824BB.5080303@zeomega.com> <48C8EE25.1000704@egenix.com> <48C93933.8000708@zeomega.com> Message-ID: <48C95913.5090607@egenix.com> On 2008-09-11 17:28, Brad Allen wrote: > > M.-A. Lemburg wrote: >> >> You have 8 '?' markers in your query, so that looks fine. However, >> the query is rather complicated with respect to all the joins, so >> it's possible that the ODBC driver doesn't parse the query correctly >> and perhaps misses out on some of the parameter markers. >> >> It may also get confused by the "_3" aliases. Why the quotes and why >> double-quotes instead of square brackets ?. What setting do you >> use for QUOTED_IDENTIFIERS ? >> > I those "_3" aliases were created by Storm's ClassAlias; I discovered a > parameter that would allow me to specify the name when creating the > ClassAlias instances. That got rid of the "_3" aliases in the query, and > there are no more quoted identifiers, and now the query is more > readable. However, it still fails when using cursor.execute and succeeds > when using cursor.executedirect. Very strange indeed. >> Some more general questions: >> >> Are you using the most recent SQL Server Native client on the >> Windows machine ? >> > I was using the normal SQL Server driver; I changed to the SQL Server > native client but am still seeing the same behavior. As far as whether > it's the latest, it's the version that comes with Windows Server 2003 > Standard Edition Service Pack 3. You can check the version number by looking at connection.driver_version I get 09.00.3042 for out installation of SQL Server native client. connection.driver_name is 'SQLNCLI.DLL'. >> How are you converting the params before using them on >> cursor.execute() ? >> > > I think Storm is handling that by building a tuple of a tuple of > strings, just like we would normally pass to cursor.execute for bind > parameters. I haven't checked to see exactly what it is doing there, but > we aren't having any issues with parameter substitution for any of our > other queries. Ok, so it's not related to data conversion either. Could you please try to run the query on a fresh new cursor (ie. one that hasn't executed any queries yet) and see whether that makes a difference ? If that doesn't help, the next thing we could try is an ODBC trace. These are the instructions to enable such a trace on Windows: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcsetting_tracing_options.asp If standard tracing doesn't work, you could try the Visual Studio Analyzer: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcenabling_visual_studio_analyzer.asp Note that tracing has to be enabled for the user account that the application is using in MDAC 2.8. There's a new option in MDAC 2.8 which also allows machine wide tracing (which was the only option in MDAC 2.7 and prior versions): http://support.microsoft.com/default.aspx?scid=kb;en-us;818489 Please send us the trace snippet for the query in question. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 11 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From kw_dev_lists at contextualcorp.com Thu Sep 11 13:21:45 2008 From: kw_dev_lists at contextualcorp.com (kw_dev_lists@contextualcorp.com) Date: Thu Sep 11 21:21:51 2008 Subject: [egenix-users] How to bypass ODBC Manager (iODBC or unixODBC) to use freetds driver Connector? Message-ID: <20080911122145.b8eb9b2469e22d4e7572761e5c168bd0.ebbde30465.wbe@email.secureserver.net> An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20080911/e5f72f1a/attachment.htm From mal at egenix.com Fri Sep 12 00:43:25 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Sep 11 23:43:30 2008 Subject: [egenix-users] How to bypass ODBC Manager (iODBC or unixODBC) to use freetds driver Connector? In-Reply-To: <20080911122145.b8eb9b2469e22d4e7572761e5c168bd0.ebbde30465.wbe@email.secureserver.net> References: <20080911122145.b8eb9b2469e22d4e7572761e5c168bd0.ebbde30465.wbe@email.secureserver.net> Message-ID: <48C990FD.9030306@egenix.com> kw_dev_lists@contextualcorp.com wrote: > Hello, > > I came across some documentation on the eGenix mxODBCZopeDA connector > for Zope indicating that the iODBC and/or unixODBC ODBC Managers for > Linux could possibly be bypassed (not used) and instead the mxODBCZopeDA > connector could be configured to directly reference a driver (freetds, > in my case on Linux RHEL 4), rather than having to go through one of the > driver managers. This can be done, but is not available for the released product, since we only include interfaces for iODBC and unixODBC. The reason for this is simple: the ODBC standard is a very complex API and the ODBC managers help work around at least some of the issues you find in practice when using ODBC drivers. (For many other quirks we have work-around in mxODBC itself.) > Can you tell me how to go about this? Where/how do I configure the mx > connector this way? I couldn't find the details in the docs or on this > list. We can provide you with custom versions for such a setup (ie. mxODBC directly linked against the FreeTDS driver), but cannot support such setups and also have to charge a support ticket for the extra work. I'd really recommend against using such a setup. It doesn't buy you anything much in terms of performance. If you're looking for better performance, it's better to look at alternative ODBC drivers for talking to MS SQL Server. We will also be releasing a mxODBC Connect Zope DA soon after the final release of mxODBC Connect, our new bridge product for working with ODBC drivers that are installed directly on the database server machine and talk to the database via shared memory and/or pipes. For MS SQL Server, you can then use a Linux client machine and work against the SQL Server Native Client installed on the Windows server. You no longer need an ODBC driver for your client machine and even get better performance due to the optimized setup. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 11 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From minh at mipscomputation.com Fri Sep 12 13:49:52 2008 From: minh at mipscomputation.com (Minh-Long Pham) Date: Fri Sep 12 21:50:36 2008 Subject: [egenix-users] Speeding up ODBC Connection Message-ID: <48CAC7E0.3010308@mipscomputation.com> Hi, I'm running mxODBC on a machine that remotely connects to the server, and when I'm executing scripts, it takes 20 minutes longer than it would on the server itself. Is there any way to speed up the connection? Thanks, Minh From mal at egenix.com Fri Sep 12 23:23:45 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Sep 12 22:23:56 2008 Subject: [egenix-users] Speeding up ODBC Connection In-Reply-To: <48CAC7E0.3010308@mipscomputation.com> References: <48CAC7E0.3010308@mipscomputation.com> Message-ID: <48CACFD1.10708@egenix.com> On 2008-09-12 21:49, Minh-Long Pham wrote: > Hi, > > I'm running mxODBC on a machine that remotely connects to the server, > and when I'm executing scripts, it takes 20 minutes longer than it would > on the server itself. > Is there any way to speed up the connection? Without more details about the used database backend, server and client platforms as well as ODBC driver, there's nothing much we can do to help. Some drivers allow tweaking the way pre-fetching and network packet sizes are handled, thus reducing the number of network round-trips. You might also want to check whether mxODBC Connect is faster for your setup: http://www.egenix.com/products/python/mxODBCConnect/ -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 12 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From ballen at zeomega.com Tue Sep 16 19:30:01 2008 From: ballen at zeomega.com (Brad Allen) Date: Wed Sep 17 02:02:07 2008 Subject: [egenix-users] cursor.executedirect configurable? In-Reply-To: <48C95913.5090607@egenix.com> References: <48C72E8F.3090109@zeomega.com> <48C78FAB.6010002@egenix.com> <48C7D020.4030908@zeomega.com> <48C7E665.7000803@egenix.com> <48C824BB.5080303@zeomega.com> <48C8EE25.1000704@egenix.com> <48C93933.8000708@zeomega.com> <48C95913.5090607@egenix.com> Message-ID: <48D04179.9080007@zeomega.com> Sorry for the delay in getting back to you on this...those Microsoft links are broken. I will try to followup with you later this week on doing an ODBC trace. M.-A. Lemburg wrote: > On 2008-09-11 17:28, Brad Allen wrote: > >> M.-A. Lemburg wrote: >> >>> You have 8 '?' markers in your query, so that looks fine. However, >>> the query is rather complicated with respect to all the joins, so >>> it's possible that the ODBC driver doesn't parse the query correctly >>> and perhaps misses out on some of the parameter markers. >>> >>> It may also get confused by the "_3" aliases. Why the quotes and why >>> double-quotes instead of square brackets ?. What setting do you >>> use for QUOTED_IDENTIFIERS ? >>> >>> >> I those "_3" aliases were created by Storm's ClassAlias; I discovered a >> parameter that would allow me to specify the name when creating the >> ClassAlias instances. That got rid of the "_3" aliases in the query, and >> there are no more quoted identifiers, and now the query is more >> readable. However, it still fails when using cursor.execute and succeeds >> when using cursor.executedirect. >> > > Very strange indeed. > > >>> Some more general questions: >>> >>> Are you using the most recent SQL Server Native client on the >>> Windows machine ? >>> >>> >> I was using the normal SQL Server driver; I changed to the SQL Server >> native client but am still seeing the same behavior. As far as whether >> it's the latest, it's the version that comes with Windows Server 2003 >> Standard Edition Service Pack 3. >> > > You can check the version number by looking at > > connection.driver_version > > I get 09.00.3042 for out installation of SQL Server native client. > connection.driver_name is 'SQLNCLI.DLL'. > > >>> How are you converting the params before using them on >>> cursor.execute() ? >>> >>> >> >> I think Storm is handling that by building a tuple of a tuple of >> strings, just like we would normally pass to cursor.execute for bind >> parameters. I haven't checked to see exactly what it is doing there, but >> we aren't having any issues with parameter substitution for any of our >> other queries. >> > > Ok, so it's not related to data conversion either. > > Could you please try to run the query on a fresh new cursor > (ie. one that hasn't executed any queries yet) and see whether > that makes a difference ? > > If that doesn't help, the next thing we could try is an > ODBC trace. These are the instructions to enable such a trace > on Windows: > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcsetting_tracing_options.asp > > If standard tracing doesn't work, you could try the > Visual Studio Analyzer: > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcenabling_visual_studio_analyzer.asp > > Note that tracing has to be enabled for the user account > that the application is using in MDAC 2.8. There's a > new option in MDAC 2.8 which also allows machine wide tracing > (which was the only option in MDAC 2.7 and prior versions): > > http://support.microsoft.com/default.aspx?scid=kb;en-us;818489 > > Please send us the trace snippet for the query in question. > > Thanks, > -- ZeOmega Open Minds' Open Solutions 3010 Gaylord Parkway, Ste. 210 Frisco TX, 75034 http://www.zeomega.com Brad Allen 214-618-9880 (ext. 8006) -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20080916/89598acf/attachment.htm From mal at egenix.com Thu Sep 18 19:15:40 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Sep 18 18:15:06 2008 Subject: [egenix-users] cursor.executedirect configurable? In-Reply-To: <48D04179.9080007@zeomega.com> References: <48C72E8F.3090109@zeomega.com> <48C78FAB.6010002@egenix.com> <48C7D020.4030908@zeomega.com> <48C7E665.7000803@egenix.com> <48C824BB.5080303@zeomega.com> <48C8EE25.1000704@egenix.com> <48C93933.8000708@zeomega.com> <48C95913.5090607@egenix.com> <48D04179.9080007@zeomega.com> Message-ID: <48D27EAC.80207@egenix.com> Brad Allen wrote: > Sorry for the delay in getting back to you on this...those Microsoft > links are broken. Oops. Sorry, that was a quote form our support wiki. MS tends to change their site structure very often. > I will try to followup with you later this week on doing an ODBC trace. Ok. > M.-A. Lemburg wrote: >> On 2008-09-11 17:28, Brad Allen wrote: >> >>> M.-A. Lemburg wrote: >>> >>>> You have 8 '?' markers in your query, so that looks fine. However, >>>> the query is rather complicated with respect to all the joins, so >>>> it's possible that the ODBC driver doesn't parse the query correctly >>>> and perhaps misses out on some of the parameter markers. >>>> >>>> It may also get confused by the "_3" aliases. Why the quotes and why >>>> double-quotes instead of square brackets ?. What setting do you >>>> use for QUOTED_IDENTIFIERS ? >>>> >>> I those "_3" aliases were created by Storm's ClassAlias; I discovered a >>> parameter that would allow me to specify the name when creating the >>> ClassAlias instances. That got rid of the "_3" aliases in the query, and >>> there are no more quoted identifiers, and now the query is more >>> readable. However, it still fails when using cursor.execute and succeeds >>> when using cursor.executedirect. >>> >> >> Very strange indeed. >> >> >>>> Some more general questions: >>>> >>>> Are you using the most recent SQL Server Native client on the >>>> Windows machine ? >>>> >>> I was using the normal SQL Server driver; I changed to the SQL Server >>> native client but am still seeing the same behavior. As far as whether >>> it's the latest, it's the version that comes with Windows Server 2003 >>> Standard Edition Service Pack 3. >>> >> >> You can check the version number by looking at >> >> connection.driver_version >> >> I get 09.00.3042 for out installation of SQL Server native client. >> connection.driver_name is 'SQLNCLI.DLL'. >> >> >>>> How are you converting the params before using them on >>>> cursor.execute() ? >>>> >>>> >>> I think Storm is handling that by building a tuple of a tuple of >>> strings, just like we would normally pass to cursor.execute for bind >>> parameters. I haven't checked to see exactly what it is doing there, but >>> we aren't having any issues with parameter substitution for any of our >>> other queries. >>> >> >> Ok, so it's not related to data conversion either. >> >> Could you please try to run the query on a fresh new cursor >> (ie. one that hasn't executed any queries yet) and see whether >> that makes a difference ? >> >> If that doesn't help, the next thing we could try is an >> ODBC trace. These are the instructions to enable such a trace >> on Windows: >> >> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcsetting_tracing_options.asp >> >> >> If standard tracing doesn't work, you could try the >> Visual Studio Analyzer: >> >> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcenabling_visual_studio_analyzer.asp >> >> >> Note that tracing has to be enabled for the user account >> that the application is using in MDAC 2.8. There's a >> new option in MDAC 2.8 which also allows machine wide tracing >> (which was the only option in MDAC 2.7 and prior versions): >> >> http://support.microsoft.com/default.aspx?scid=kb;en-us;818489 >> >> Please send us the trace snippet for the query in question. >> >> Thanks, >> > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From kw_dev_lists at contextualcorp.com Thu Sep 18 15:37:43 2008 From: kw_dev_lists at contextualcorp.com (kw_dev_lists@contextualcorp.com) Date: Thu Sep 18 23:37:49 2008 Subject: [egenix-users] Getting mxODBCZopeDA connector to pick-up environment ODBC DNSs Message-ID: <20080918143743.b8eb9b2469e22d4e7572761e5c168bd0.647b472108.wbe@email.secureserver.net> An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20080918/3f50ffb9/attachment.htm From charlie at egenix.com Fri Sep 19 15:52:40 2008 From: charlie at egenix.com (Charlie Clark) Date: Fri Sep 19 14:52:50 2008 Subject: [egenix-users] Getting mxODBCZopeDA connector to pick-up environment ODBC DNSs In-Reply-To: <20080918143743.b8eb9b2469e22d4e7572761e5c168bd0.647b472108.wbe@email.secureserver.net> References: <20080918143743.b8eb9b2469e22d4e7572761e5c168bd0.647b472108.wbe@email.secureserver.net> Message-ID: Am 18.09.2008, 23:37 Uhr, schrieb : > Hi, > > I've got freetds and unixODBC working fine from the command line (tsql > test, for example) on a server, but when I create an eGenix mxODBC > connection in Zope 2.9 to an MS SQL Server database, it's not finding > the environment connections (DSNs) defined in the ODBC.ini. > > What's the best way to get it to pick these settings up, so that when I > click on 'Available Datasources' in the connection object, it'll show > them and can connect to them? > > Should I add an environment variable ODBCINI= to the zope.conf file? No, that isn't necessary. The usual problem with data sources, drivers and the like is making sure that the permissions are correct, ie. so that the Zope user can access them. When testing on the command line you will normally be using your own user account. Charlie -- Charlie Clark eGenix.com Professional Python Services directly from the Source >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From kw_dev_lists at contextualcorp.com Fri Sep 19 12:02:47 2008 From: kw_dev_lists at contextualcorp.com (kw_dev_lists@contextualcorp.com) Date: Fri Sep 19 20:02:59 2008 Subject: [egenix-users] Getting mxODBCZopeDA connector to pick-up environment ODBC DNSs Message-ID: <20080919110247.b8eb9b2469e22d4e7572761e5c168bd0.ea23b9ff25.wbe@email.secureserver.net> An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20080919/c81e008f/attachment.htm From mal at egenix.com Mon Sep 22 12:37:14 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Sep 22 11:37:20 2008 Subject: [egenix-users] Getting mxODBCZopeDA connector to pick-up environment ODBC DNSs In-Reply-To: <20080919110247.b8eb9b2469e22d4e7572761e5c168bd0.ea23b9ff25.wbe@email.secureserver.net> References: <20080919110247.b8eb9b2469e22d4e7572761e5c168bd0.ea23b9ff25.wbe@email.secureserver.net> Message-ID: <48D7674A.6000208@egenix.com> On 2008-09-19 20:02, kw_dev_lists@contextualcorp.com wrote: > I have freetds and unixODBC under /usr/lib/zopeODBC and these folders are owned > by the same user:group that my zope instance is owned by and that zope runs under. > > The mxODBC connector doesn't seem to be able to find the drivers under > /user/lib/zopeODBC/unixODBC or .../freetds. > > Do I need to add an PATH environment variable to zope.conf or something, so > these can be found? > > Here's the error from the zope event.log: > > ------ > 2008-09-19T12:56:24 ERROR Zope Couldn't install mxODBCZopeDA > Traceback (most recent call last): > File "/usr/local/apps/zope/core/Z298/lib/python/OFS/Application.py", line 755, > in install_product > File "Products/mxODBCZopeDA/__init__.py", line 7, in ? > # Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution. > File "Products/mxODBCZopeDA/ZopeDA.py", line 254, in ? > File "Products/mxODBCZopeDA/ZopeDA.py", line 246, in find_subpackages > ImportError: no usable mxODBC subpackage found: iODBC: libiodbc.so.2: cannot > open shared object file: No such file or directory; unixODBC: libodbc.so.1: > cannot open shared object file: No such file or directory mxODBC cannot load the unixODBC manager shared libraries. You will either have to add the path to these to your system configuration file ld.so.conf or setup LD_LIBRARY_PATH to include them. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 22 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 > ------ > 2008-09-19T12:56:24 INFO Zope Ready to handle requests > ------ > 2008-09-19T12:56:25 WARNING ZODB Could not import class 'ZopeConnection' from > module 'Products.mxODBCZopeDA.ZopeDA' > > > Thanks, > Ken > > -------- Original Message -------- > Subject: Re: [egenix-users] Getting mxODBCZopeDA connector to pick-up > environment ODBC DNSs > From: "Charlie Clark" > Date: Fri, September 19, 2008 5:52 am > To: kw_dev_lists@contextualcorp.com, egenix-users@egenix.com > > Am 18.09.2008, 23:37 Uhr, schrieb : > > > Hi, > > > > I've got freetds and unixODBC working fine from the command line (tsql > > test, for example) on a server, but when I create an eGenix mxODBC > > connection in Zope 2.9 to an MS SQL Server database, it's not finding > > the environment connections (DSNs) defined in the ODBC.ini. > > > > What's the best way to get it to pick these settings up, so that when I > > click on 'Available Datasources' in the connection object, it'll show > > them and can connect to them? > > > > Should I add an environment variable ODBCINI= to the zope.conf file? > > No, that isn't necessary. The usual problem with data sources, drivers and > the like is making sure that the permissions are correct, ie. so that the > Zope user can access them. When testing on the command line you will > normally be using your own user account. > > Charlie > -- > Charlie Clark > eGenix.com > > Professional Python Services directly from the Source > > >> Python/Zope Consulting and Support ... http://www.egenix.com/ > > >> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ > > >> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ > ________________________________________________________________________ > > :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: > > eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 > D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg > Registered at Amtsgericht Duesseldorf: HRB 46611 > > > ------------------------------------------------------------------------ > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > https://www.egenix.com/mailman/listinfo/egenix-users From info at egenix.com Thu Sep 25 16:57:12 2008 From: info at egenix.com (eGenix Team: M.-A. Lemburg) Date: Thu Sep 25 16:03:38 2008 Subject: [egenix-users] ANN: eGenix pyOpenSSL Distribution 0.7.0-0.9.8i-1 Message-ID: <48DB98B8.6050308@egenix.com> ________________________________________________________________________ ANNOUNCING eGenix.com pyOpenSSL Distribution Version 0.7.0-0.9.8i-1 An easy to install and use repackaged distribution of the pyOpenSSL Python interface for OpenSSL - available on Windows and Unix platforms This announcement is also available on our web-site for online reading: http://www.egenix.com/company/news/eGenix-pyOpenSSL-Distribution-0.7.0-0.9.8i-1-GA.html ________________________________________________________________________ INTRODUCTION The eGenix.com pyOpenSSL Distribution includes everything you need to get started with SSL in Python. It comes with an easy to use installer that includes the most recent OpenSSL library versions in pre-compiled form. pyOpenSSL is an open-source Python add-on (http://pyopenssl.sf.net/) that allows writing SSL aware networking applications as well as certificate management tools. OpenSSL is an open-source implementation of the SSL protocol (http://www.openssl.org/). * About Python: Python is an object-oriented Open Source programming language which runs on all modern platforms (http://www.python.org/). By integrating ease-of-use, clarity in coding, enterprise application connectivity and rapid application design, Python establishes an ideal programming platform for todays IT challenges. * About eGenix: eGenix is a consulting and software product company focused on providing professional quality services and products to Python users and developers (http://www.egenix.com/). ________________________________________________________________________ NEWS This second release of the eGenix.com pyOpenSSL Distribution upgrades the included OpenSSL library version to the latest 0.9.8i, which includes several bug fixes over the previously included 0.9.8h version. The release also includes Python 2.6 support for the first time. Binaries are available for Linux x86 and x64 as well as Windows x86. ________________________________________________________________________ DOWNLOADS The download archives and instructions for installing the package can be found at: http://www.egenix.com/products/python/pyOpenSSL/ ________________________________________________________________________ UPGRADING Before installing this version of pyOpenSSL, please make sure that you uninstall any previously installed pyOpenSSL version. Otherwise, you could end up not using the included OpenSSL libs. _______________________________________________________________________ SUPPORT Commercial support for these packages is available from eGenix.com. Please see http://www.egenix.com/services/support/ for details about our support offerings. Enjoy, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 25 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From mal at egenix.com Thu Sep 25 20:38:09 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Sep 25 19:38:18 2008 Subject: [egenix-users] ANN: eGenix pyOpenSSL Distribution 0.7.0-0.9.8i-1 In-Reply-To: <48DB98B8.6050308@egenix.com> References: <48DB98B8.6050308@egenix.com> Message-ID: <48DBCC81.6010701@egenix.com> Dear Users, due to a problem with the upload to our server, the distribution files were not accessible. The problem has now been corrected. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 25 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 On 2008-09-25 15:57, eGenix Team: M.-A. Lemburg wrote: > ________________________________________________________________________ > > ANNOUNCING > > eGenix.com pyOpenSSL Distribution > > Version 0.7.0-0.9.8i-1 > > > An easy to install and use repackaged distribution > of the pyOpenSSL Python interface for OpenSSL - > available on Windows and Unix platforms > > > This announcement is also available on our web-site for online reading: > http://www.egenix.com/company/news/eGenix-pyOpenSSL-Distribution-0.7.0-0.9.8i-1-GA.html > > ________________________________________________________________________ > > INTRODUCTION > > The eGenix.com pyOpenSSL Distribution includes everything you need to > get started with SSL in Python. It comes with an easy to use installer > that includes the most recent OpenSSL library versions in pre-compiled > form. > > pyOpenSSL is an open-source Python add-on (http://pyopenssl.sf.net/) > that allows writing SSL aware networking applications as well as > certificate management tools. > > OpenSSL is an open-source implementation of the SSL protocol > (http://www.openssl.org/). > > * About Python: > Python is an object-oriented Open Source programming language which > runs on all modern platforms (http://www.python.org/). By integrating > ease-of-use, clarity in coding, enterprise application connectivity > and rapid application design, Python establishes an ideal programming > platform for todays IT challenges. > > * About eGenix: > eGenix is a consulting and software product company focused on > providing professional quality services and products to Python > users and developers (http://www.egenix.com/). > > ________________________________________________________________________ > > NEWS > > This second release of the eGenix.com pyOpenSSL Distribution upgrades > the included OpenSSL library version to the latest 0.9.8i, which includes > several bug fixes over the previously included 0.9.8h version. > > The release also includes Python 2.6 support for the first time. > > Binaries are available for Linux x86 and x64 as well as Windows x86. > > ________________________________________________________________________ > > DOWNLOADS > > The download archives and instructions for installing the package can > be found at: > > http://www.egenix.com/products/python/pyOpenSSL/ > > ________________________________________________________________________ > > UPGRADING > > Before installing this version of pyOpenSSL, please make sure that > you uninstall any previously installed pyOpenSSL version. Otherwise, > you could end up not using the included OpenSSL libs. > > _______________________________________________________________________ > > SUPPORT > > Commercial support for these packages is available from eGenix.com. > Please see > > http://www.egenix.com/services/support/ > > for details about our support offerings. > > Enjoy,