Python-сообщество

4kpt_IV
Как и обещал Видео доклада по SQLAlchemy

Спасибо за доклад, но проблемы с кодировками там как раз не освещены.

Это не совсем проблемы, а настройка движка для алхимии. Есть прямо в документации.

4kpt_IV
Это не совсем проблемы, а настройка движка для алхимии. Есть прямо в документации.

Делаем настройки:
engine = create_engine('mssql+pymssql/test:test@10.1.1.1/TST1', encoding='cp1251', convert_unicode=True)

Если я их правильно понял - encoding говорит, что база в 1251, а convert - что строки из базы должны возвращаться в unicode. Должны, но возвращаются в 1251.

Al-se
А как на Ваш вопрос отвечает документация? Именно api create_engine?

Отредактировано 4kpt_IV (Янв. 31, 2017 16:16:32)

4kpt_IV
Al-seА как на Ваш вопрос отвечает документация? Именно api create_engine?

Я вернулся, но ничего утешительного для меня. Итак, пытаемся воспользоваться Вам советом и почитать документацию.

convert_unicode=False¶ –
if set to True, sets the default behavior of convert_unicode on the String type to True, regardless of a setting of False on an individual String type, thus causing all String -based columns to accommodate Python unicode objects. This flag is useful as an engine-wide setting when using a DBAPI that does not natively support Python unicode objects and raises an error when one is received (such as pyodbc with FreeTDS).

See String for further details on what this flag indicates.

encoding¶ –
Defaults to utf-8. This is the string encoding used by SQLAlchemy for string encode/decode operations which occur within SQLAlchemy, outside of the DBAPI. Most modern DBAPIs feature some degree of direct support for Python unicode objects, what you see in Python 2 as a string of the form u'some string'. For those scenarios where the DBAPI is detected as not supporting a Python unicode object, this encoding is used to determine the source/destination encoding. It is not used for those cases where the DBAPI handles unicode directly.

To properly configure a system to accommodate Python unicode objects, the DBAPI should be configured to handle unicode to the greatest degree as is appropriate - see the notes on unicode pertaining to the specific target database in use at Dialects.

Areas where string encoding may need to be accommodated outside of the DBAPI include zero or more of:

the values passed to bound parameters, corresponding to the Unicode type or the String type when convert_unicode is True;
the values returned in result set columns corresponding to the Unicode type or the String type when convert_unicode is True;
the string SQL statement passed to the DBAPI’s cursor.execute() method;
the string names of the keys in the bound parameter dictionary passed to the DBAPI’s cursor.execute() as well as cursor.setinputsizes() methods;
the string column names retrieved from the DBAPI’s cursor.description attribute.
When using Python 3, the DBAPI is required to support all of the above values as Python unicode objects, which in Python 3 are just known as str.

В общем, оба варианта попробовал - не работает так, как мне надо.

Al-se

Поинтересуюсь, почему выбрали pymssql для соединения с sql а не pyodbc к примеру?

101s

Нашел на сайте Микрософт.

Al-se
Приношу свои извинения, но помочь больше нечем. Потому как у меня нет этой БД (и не будет), а попробовать негде. На самом деле нужно смотреть под каким python Вы работаете и что передаете. Т.е. вопросов много и подобрать правильную конфигурацию под Ваши задачи сможете только Вы

4kpt_IV
Al-seПриношу свои извинения, но помочь больше нечем. Потому как у меня нет этой БД (и не будет), а попробовать негде. На самом деле нужно смотреть под каким python Вы работаете и что передаете. Т.е. вопросов много и подобрать правильную конфигурацию под Ваши задачи сможете только Вы

Я в первом посте написал - Питон 3.5. На самом деле, как я понял, и моё решение и то, что предложили Вы с помощью Алхимии, упирается в одну и ту же проблему кодировок и представления данных.
В моем решении (см. первый пост темы), чтобы работал поиск в базе с данными в 1251 необходимо в запрос (т.е. в строку питона) передать коды в 1251. Т.к. у меня правильно не получилось, то соответственно поиск в базе, где в данных есть не только цифры, а и русские буквы, не работает (в смысле не находит того, чего нужно, хотя ошибок и не дает).
В Вашем решении (с использованием Алхимии) она корректно перекодировала в поисковом запросе в 1251 всё, что нужно. Поэтому нужная строка нашлась, но если в возвращаемых данных (которые в 1251) есть русские буквы, то перекодируется всё неправильно и получить строку (для дальнейшей работы) в понимании Питона 3.х не удается.

Отредактировано Al-se (Фев. 9, 2017 09:24:40)

Соболезную. Посоветовать только могу или пошаманить с кодировками или заюзать нормальную базу данных. Если же это уже готовый проект, тогда соболезную вдвойне