Связи Python pyobbc с IBM Netezza Ошибка

Question

So. Эта проблема почти такая же, как обсуждавшаяся here, но исправление (такое как оно есть), обсуждаемое в этом сообщении, не помогает мне.

Я пытаюсь использовать Python 2.7.5 и pyodbc 3.0.7 для подключения с 64-битной машины Ubuntu 12.04 к базе данных IBM Netezza. Я использую unixODBC для обработки DSN. Этот DSN прекрасно работает с CLI isql, поэтому я знаю, что он настроен правильно, и unixODBC тикает прямо.

Код в настоящее время мертв просто и легко воспроизвести в РЕПЛ:

In [1]: import pyodbc 
In [2]: conn = pyodbc.connect(dsn='NZSQL') 
In [3]: curs = conn.cursor() 
In [4]: curs.execute("SELECT * FROM DB..FOO ORDER BY created_on DESC LIMIT 10") 
Out[4]: <pyodbc.Cursor at 0x1a70ab0> 

In [5]: curs.fetchall() 
--------------------------------------------------------------------------- 
InvalidOperation       Traceback (most recent call last) 
<ipython-input-5-ad813e4432e9> in <module>() 
----> 1 curs.fetchall() 

/usr/lib/python2.7/decimal.pyc in __new__(cls, value, context) 
    546      context = getcontext() 
    547     return context._raise_error(ConversionSyntax, 
--> 548         "Invalid literal for Decimal: %r" % value) 
    549 
    550    if m.group('sign') == "-": 

/usr/lib/python2.7/decimal.pyc in _raise_error(self, condition, explanation, *args) 
    3864   # Errors should only be risked on copies of the context 
    3865   # self._ignored_flags = [] 
-> 3866   raise error(explanation) 
    3867 
    3868  def _ignore_all_flags(self): 

InvalidOperation: Invalid literal for Decimal: u'' 

Так я получаю соединение, запрос возвращает правильно, а затем, когда я пытаюсь получить ряд ... asplode ,

Никто никогда не мог это сделать?

Answer 1

Оказывается pyodbc не может корректно преобразовать все типы Netezza в. Стол я работал с имел два, которые являются проблематичными:

• столбца типа NUMERIC(7,2)
• Колонны типа NVARCHAR(255)

колонок NUMERIC вызывает десятичную ошибку преобразования на NULL. Столбец NVARCHAR возвращает строку, закодированную utf-16-le, которая является болью в заднице.

Я еще не нашел хорошего решения на уровне драйвера или оболочки. Это может быть взломан путем литья типов в операторе SQL:

SELECT 
    foo::FLOAT AS was_numeric 
    , bar::VARCHAR(255) AS was_nvarchar 

я выложу здесь, если я найду ответ низкого уровня.

Answer 2

Я не уверен, что ваша ошибка, но ниже код позволяет мне подключиться к Netezza через ODBC:

# Connect via pyodbc to listed data sources on machine 
import pyodbc 
print pyodbc.dataSources() 

print "Connecting via ODBC" 

# get a connection, if a connect cannot be made an exception will be raised here 
conn = pyodbc.connect("DRIVER={NetezzaSQL};SERVER=<myserver>;PORT=<myport>;DATABASE=<mydbschema>;UID=<user>;PWD=<password>;") 

print "Connected!\n" 

# you can then use conn cursor to perform queries 

Answer 3

Я столкнулся с той же проблемой и нашел другое решение. мне удалось решить эту проблему путем:

1. Убедившись следующие атрибуты являются частью моих вариантов драйверов в Odbc ини файле:

   • UnicodeTranslationOption = utf16
   • CharacterTranslationOption = все

2. Добавить следующие переменные окружения:

   • LD_LIBRARY_PATH = $ LD_LIBRARY_PATH: [NETEZZA_LIB_FILES_PATH]
   • ODBCINI = [ODBC_INI_FULL_PATH]
   • NZ_ODBC_INI_PATH = [ODBC_INI_FOLDER_PATH]

   В моем случае значения:

   • LD_LIBRARY_PATH = $ LD_LIBRARY_PATH:/usr/local/nz/lib
   • ODBC_INI =/etc/odbc.ini
   • NZ_ODBC_INI_PATH =/и т.д.

Я использую CentOS 6, а также установлен как 'UnixODBC' и 'UnixODBC-разви' пакеты.

Надеюсь, это поможет кому-то.

Answer 4

Клиентский пакет Netezza Linux включает в себя /usr/local/nz/lib/ODBC_README, в котором перечислены все значения для этих двух атрибутов:

UnicodeTranslationOption: 
    Specify translation option for Unicode. 
    Possible value strings are: 
     utf8 : unicode data is in utf-8 encoding 
     utf16 : unicode data is in utf-16 encoding 
     utf32 : unicode data is in utf-32 encoding 
    Do not add '-' in the value strings listed above, e.g. "utf-8" is not 
    a valid string value. These value strings are case insensitive. 

    On windows this option is not available as windows DM always passes 
    unicode data in utf16. 

CharacterTranslationOption ("Optimize for ASCII character set" on Windows): 
    Specify translation option for character encodings. 
    Possible value strings are: 
     all  : Support all character encodings 
     latin9 : Support Latin9 character encoding only 
    Do not add '-' in the value strings listed above, e.g. "latin-9" 
    is not a valid string value. These value strings are case 
    insensitive. 

    NPS uses the Latin9 character encoding for char and varchar 
    datatypes. The character encoding on many Windows systems 
    is similar, but not identical to this. For the ASCII subset 
    (letters a-z, A-Z, numbers 0-9 and punctuation marks) they are 
    identical. If your character data in CHAR or VARCHAR datatypes is 
    only in this ASCII subset then it will be faster if this box is 
    checked. If your data has special characters such as the Euro 
    sign (€) then keep the box unchecked to accurately convert 
    the encoding. Characters in the NCHAR or NVARCHAR data types 
    will always be converted appropriately.