Open GoogleCodeExporter opened 8 years ago
This is the result of the build, perhaps it is useful.
~/pyodbc-3.0.7$ sudo python setup.py build
running build
running build_ext
building 'pyodbc' extension
creating build
creating build/temp.linux-x86_64-3.3
creating build/temp.linux-x86_64-3.3/datos
creating build/temp.linux-x86_64-3.3/datos/usuarios
creating build/temp.linux-x86_64-3.3/home/user
creating build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7
creating build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -fPIC -DPYODBC_VERSION=3.0.7 -I/usr/include/python3.3m -c
/home/user/pyodbc-3.0.7/src/pyodbcmodule.cpp -o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/pyodbcmodule.o
-Wno-write-strings
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for
C/ObjC but not for C++ [enabled by default]
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -fPIC -DPYODBC_VERSION=3.0.7 -I/usr/include/python3.3m -c
/home/user/pyodbc-3.0.7/src/buffer.cpp -o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/buffer.o
-Wno-write-strings
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for
C/ObjC but not for C++ [enabled by default]
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -fPIC -DPYODBC_VERSION=3.0.7 -I/usr/include/python3.3m -c
/home/user/pyodbc-3.0.7/src/connection.cpp -o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/connection.o
-Wno-write-strings
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for
C/ObjC but not for C++ [enabled by default]
/home/user/pyodbc-3.0.7/src/connection.cpp: In function ‘PyObject*
Connection_getinfo(PyObject*, PyObject*)’:
/home/user/pyodbc-3.0.7/src/connection.cpp:600:40: warning: dereferencing
type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
SQLUINTEGER n = *(SQLUINTEGER*)szBuffer; // Does this work on PPC or do we need a union?
^
/home/user/pyodbc-3.0.7/src/connection.cpp:613:49: warning: dereferencing
type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
result = PyInt_FromLong(*(SQLUSMALLINT*)szBuffer);
^
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -fPIC -DPYODBC_VERSION=3.0.7 -I/usr/include/python3.3m -c
/home/user/pyodbc-3.0.7/src/row.cpp -o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/row.o -Wno-write-strings
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for
C/ObjC but not for C++ [enabled by default]
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -fPIC -DPYODBC_VERSION=3.0.7 -I/usr/include/python3.3m -c
/home/user/pyodbc-3.0.7/src/cursor.cpp -o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/cursor.o
-Wno-write-strings
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for
C/ObjC but not for C++ [enabled by default]
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -fPIC -DPYODBC_VERSION=3.0.7 -I/usr/include/python3.3m -c
/home/user/pyodbc-3.0.7/src/params.cpp -o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/params.o
-Wno-write-strings
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for
C/ObjC but not for C++ [enabled by default]
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -fPIC -DPYODBC_VERSION=3.0.7 -I/usr/include/python3.3m -c
/home/user/pyodbc-3.0.7/src/sqlwchar.cpp -o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/sqlwchar.o
-Wno-write-strings
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for
C/ObjC but not for C++ [enabled by default]
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -fPIC -DPYODBC_VERSION=3.0.7 -I/usr/include/python3.3m -c
/home/user/pyodbc-3.0.7/src/cnxninfo.cpp -o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/cnxninfo.o
-Wno-write-strings
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for
C/ObjC but not for C++ [enabled by default]
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -fPIC -DPYODBC_VERSION=3.0.7 -I/usr/include/python3.3m -c
/home/user/pyodbc-3.0.7/src/getdata.cpp -o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/getdata.o
-Wno-write-strings
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for
C/ObjC but not for C++ [enabled by default]
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -fPIC -DPYODBC_VERSION=3.0.7 -I/usr/include/python3.3m -c
/home/user/pyodbc-3.0.7/src/pyodbcdbg.cpp -o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/pyodbcdbg.o
-Wno-write-strings
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for
C/ObjC but not for C++ [enabled by default]
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -fPIC -DPYODBC_VERSION=3.0.7 -I/usr/include/python3.3m -c
/home/user/pyodbc-3.0.7/src/pyodbccompat.cpp -o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/pyodbccompat.o
-Wno-write-strings
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for
C/ObjC but not for C++ [enabled by default]
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -fPIC -DPYODBC_VERSION=3.0.7 -I/usr/include/python3.3m -c
/home/user/pyodbc-3.0.7/src/errors.cpp -o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/errors.o
-Wno-write-strings
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for
C/ObjC but not for C++ [enabled by default]
creating build/lib.linux-x86_64-3.3
x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions
-Wl,-Bsymbolic-functions -Wl,-z,relro -Wno-unused-result -DNDEBUG -g -fwrapv
-O2 -Wall -Wstrict-prototypes -g -fstack-protector --param=ssp-buffer-size=4
-Wformat -Werror=format-security -Wl,-Bsymbolic-functions -Wl,-z,relro -g
-fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/pyodbcmodule.o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/buffer.o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/connection.o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/row.o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/cursor.o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/params.o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/sqlwchar.o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/cnxninfo.o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/getdata.o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/pyodbcdbg.o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/pyodbccompat.o
build/temp.linux-x86_64-3.3/home/user/pyodbc-3.0.7/src/errors.o -lodbc -o
build/lib.linux-x86_64-3.3/pyodbc.cpython-33m.so
~/pyodbc-3.0.7$ sudo python setup.py install
running install
running build
running build_ext
running install_lib
copying build/lib.linux-x86_64-3.3/pyodbc.cpython-33m.so ->
/usr/local/lib/python3.3/dist-packages
running install_egg_info
Removing /usr/local/lib/python3.3/dist-packages/pyodbc-3.0.7.egg-info
Writing /usr/local/lib/python3.3/dist-packages/pyodbc-3.0.7.egg-info
Thanks!
Original comment by a.navarr...@gmail.com
on 26 Aug 2014 at 8:46
Same issue on Ubuntu 15.4 with Python 3.4 and latest PyODBC.
Same code works on windows under python 3.2.
Original comment by tswor...@gmail.com
on 26 Apr 2015 at 5:39
wanted to follow up. In my case the ODBC driver (NetezzaSQL) was set to use
UTF8. I first though the issue was either a UC2 or UC4 build of Python. Both
made no difference. Switching the driver to UTF16
(UnicodeTranslationOption=utf16) fixed the issue for me.
Original comment by tswor...@gmail.com
on 26 Apr 2015 at 6:42
I am trying to connect Netezza with Python3.4 on Ubuntu 14.04 . I have pyodbc 3.0.10 installed on my system
I am also facing the same issue. I have also mentioned UnicodeTranslationOption=utf16
in my odbc*.ini
files but still getting the error.
My code is working fine with Python 2.7., and I am also able to make connection via strace isql
. But with Python 3.4, on doing execute, I am getting error as:
>>> cursor.execute("SELECT * FROM xxx.yyy.zzz LIMIT 100;")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
pyodbc.ProgrammingError: ('42000', '[42000] ERROR: \'S\'\nerror ^ found "S" (at char 1) expecting a keyword (27) (SQLExecDirectW)')
Can anyone please help me with this? Any idea regarding issue or path in which I should move?
Also, Since my code is running on Python 2.7, does that mean UnicodeTranslationOption
parameter is set correctly?
And, It is mentioned in document to configure PyODBC that I should build Python with UCS2 version. But on my machine, both Python2.7 and Python3.4 says they have UCS4 version, and since code is running on Python 2.x, that means UCS4 is not the issue here. Right?
Hola. Just wanted to chime in and say that I too am having this issue with Pyodbc and Netezza.
Pyodbc 4.0.14, Ubuntu 16.04, Python 3.5.2. I tried switching over to UTF16, but no luck.
I encountered the same issue when connecting to to netezza from redhat with py3.5.2. No issues with py2.7.
redhat 7.3, pyodbc=3.0.10.
After posting this, I found the issue. It's detailed here:
http://blog.novaslp.net/post/117406796793/unixodbc-python3-netezza-pyodbcceodbc-hell
The key problem, at least for me using Netezza is that unixodbc uses odbcinst.ini in /etc, while the Netezza driver looks for a hidden version in ~/.odbcinst.ini! I linked my personal one to the one in /etc. If you have two copies, you have to change them on both. I now can write queries to netezza in that Pyodbc4.0.14/ubuntu 16.04/Python 3.5.2 environment.
So, in short, this is probably not a Pyodbc issue, but nonsense from unixodbc and IBM.
I've checked the configuation settings are in place regarding the UnicodeTranslationOption = utf16,
I was aware of the potential issues regarding nz home directory ~/.odbc*.ini files, however had the NZ_ODBC_INI set appropriately. Regardless, I tried copies of the odbcinst and odbcini in the home directory, reloaded the profile and attempted again.
I seem to be experiencing the same issues as moin, on RHEL using Python 3.6 with pyodbc (4.0.23).
Since the queries I execute are files, I attempted to pass in files converted to utf-8 / utf16 using iconv (and checking them before use) and still encountered similar issues, where the first character cannot be read. Interestingly with a utf-8 string I get the message "pyodbc Error: ('HY000', '[HY000] ERROR: Input is not UTF-8\n (46) (SQLExecDirectW)')" and with utf16 "UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte". This might not have been the best approach to test.
In the meantime I'm relying on a fallback and am using the default Python 2.6.6 environment with an older version of pyodbc (3.0.10), (with the same unixodbc and nz environment ) and works fine. The same code also works fine on a windows environment, with Python 3.54 and pyodbc 4.0.19. The only downside to this is that the it fails on converting null numeric(12,0) unless I convert to characters, which thankfully is a rare occurance in my datasets.
Original issue reported on code.google.com by
a.navarr...@gmail.com
on 26 Aug 2014 at 8:36