Найти - Пользователи
Полная версия: Проблема с pymssql
Начало » Базы данных » Проблема с pymssql
1 2 3
Андрей Светлов
NTWDBLIB.DLL сравнить бы - на обоих машинах. Заодно вопрос: у вас везде win32, или есть win64?
DuoV
Андрей Светлов
NTWDBLIB.DLL сравнить бы - на обоих машинах. Заодно вопрос: у вас везде win32, или есть win64?
Библиотека идет в комплекте с модулем. Размер один в один на двух машинах. Обе машины win32. Но благодаря вашему сообщению, закрался червяк сомнения. Проверил контрольные суммы библиотек и о чудо - они разные, как так получается при установки не знаю. Вообщем перенес библиотеку простым копированием, проверил дальше зависимости - ntwdblib нормально скушалась. Далее докинул еще недостающие библиотеки которые указал Depency Walker и все заработало.
Огромное спасибо всем за советы, и персональное Андрею Светлову.
P.S. вопрос не в тему, но может кто на вскидку ответит. Почему то оператор continue работает в linux и windows по разному. В линуксе, все верно, перекидывает на следующую итерацию в цикле, а в винде работает как break, то есть выходит из цикла. Это нормально?
Ferroman
Нет не нормально. А можно пример кода где такое происходит?
DuoV
Ferroman
Нет не нормально. А можно пример кода где такое происходит?
Извиняюсь, моя ошибка, все нормально с continue. Просто у меня цикл по разному отрабатываеться на linux и на windows. возможно дело опять в pymssql и разной отработке cursor.fetchone().
#фрагмент кода
#определяем базу данных
scur = db.cursor()
scur.execute(' SELECT * FROM table")
row = scur.fetchone()
while row:
#do something
row = scur.fetchone()
то есть по описанию fetchone() берет по одному списку и убирает его из курсора. В итоге данный цикл на линуксе прогоняеться по числу строк в таблице, а в виндоусе только один раз почему то. Попробую fetchall().
DuoV
Да проблема оказалась в том что fetchone() отрабатываеться по разному на винде и линуксе. Сменил на
rowall = scur.fetchall()
for row in rowall:
#do something
и все заработало.
Что то в итоге меня как то pymssql слегка разочаровал. Попробую посмотреть в сторону pyODBC.
Вопрос можно закрывать. Еще раз всем спасибо.
regall
DuoV
Попробую посмотреть в сторону pyODBC.
Говорили же, еще в начале темы =). Китайская пословица гласит: дурак учится на своих ошибках, умный - на чужих, а мудрый ошибок не делает…
DuoV
regall
DuoV
Попробую посмотреть в сторону pyODBC.
Говорили же, еще в начале темы =). Китайская пословица гласит: дурак учится на своих ошибках, умный - на чужих, а мудрый ошибок не делает…
Зато на своих эфективней. Лучше в память врезаются. Да и много полезного узнал по ходу. В линуксе впринципе pymssql работает на ура и не надо мутить с одбц. А вот в винде начинается веселье.
regall
DuoV
В линуксе впринципе pymssql работает на ура  и не надо мутить с одбц. А вот в винде начинается веселье.
Мое мнение таково, что в разработке на python надо стараться использовать преимущество кросс-платформенности, особенно если вы точно знаете, что ваше приложение будет работать на разных платформах, и даже если вы в начале проекта не предполагаете такую возможность (это из личного опыта)… Сразу пример:

делал небольшое GUI-приложение на wxWidgets + mySQL, потом легким движением руки заказчика MySQL плавно перешел в MSSQL, а потом, омг, на FireBird, тогда я ОЧЕНЬ четко осознал преимущества pyodbc =). Ну это так, к размышлению …
Ferroman
http://www.sqlalchemy.org/features.html
SQLAlchemy includes dialects for SQLite, Postgres, MySQL, Oracle, MS-SQL, Firebird, MaxDB, MS Access, Sybase and Informix;
DuoV
2 Светлов:
Спасибо, учту на будущее. Надо только разобраться как сделать чтобы одно приложение работало под разными кодировками для разных платформ.
2 Ferroman:
Спасибо за наводку. Погляжу что за зверь такой.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB