このエラーが発生する理由がわからず、解決策が見つかりません。 freetdstsqlを使用してSQLServerデータベースに接続できますが、pymssql.connect
を使用して接続するとエラーが発生し続けます。
特定のエラーは次のとおりです。
pymssql.OperationalError:(18456、 "ユーザー 'xxx'のログインに失敗しました。DB-Libエラーメッセージ18456、重大度14:\ n一般的なSQLServerエラー:SQLServerからのメッセージを確認してください\ nDB-Libエラーメッセージ20002、重大度9:\ nAdaptiveServer接続に失敗しました\ n ")
Freetdsの構成を次のように設定しています。
[custom_config]
Host = myhost
port = 1433
tds version = 7.0
encryption = request
dump file = /tmp/freetds.log
ランニング:
tsql -S custom_config -U tsmv -P xxx
戻り値:
locale is "en_US.UTF-8"
locale charset is "UTF-8"
using default charset "UTF-8"
1>
これにより、データベースにクエリを実行できます。
ただし、実行中:
python
>> import pymssql
>> pymssql.connect(server='custom_config', user='user', password='xxx', database='database')
上記のエラーが発生します。
Linux CentOS、python 2.6.6、freetds 0.92 devを使用しています(tdsver = 7.0でコンパイルする他のバージョンを試しました)。
Freetdsログは次のとおりです。
log.c:196:Starting log file for FreeTDS 0.92
on 2012-04-12 10:39:15 with debug flags 0x4fff.
iconv.c:330:tds_iconv_open(0x1391b70, ISO-8859-1)
iconv.c:187:local name for ISO-8859-1 is ISO-8859-1
iconv.c:187:local name for UTF-8 is UTF-8
iconv.c:187:local name for UCS-2LE is UCS-2LE
iconv.c:187:local name for UCS-2BE is UCS-2BE
iconv.c:349:setting up conversions for client charset "ISO-8859-1"
iconv.c:351:preparing iconv for "ISO-8859-1" <-> "UCS-2LE" conversion
iconv.c:391:preparing iconv for "ISO-8859-1" <-> "UCS-2LE" conversion
iconv.c:394:tds_iconv_open: done
net.c:205:Connecting to xx.x.x.xxx port 1433 (TDS version 7.1)
net.c:270:tds_open_socket: connect(2) returned "Operation now in progress"
net.c:310:tds_open_socket() succeeded
util.c:156:Changed query state from DEAD to IDLE
net.c:741:Sending packet
0000 12 01 00 34 00 00 00 00-00 00 15 00 06 01 00 1b |...4.... ........|
0010 00 01 02 00 1c 00 0c 03-00 28 00 04 ff 08 00 01 |........ .(......|
0020 55 00 00 02 4d 53 53 51-4c 53 65 72 76 65 72 00 |U...MSSQ LServer.|
0030 c7 39 00 00 - |.9..|
net.c:555:Received header
0000 04 01 00 25 00 00 01 00- |...%....|
net.c:609:Received packet
0000 04 01 00 25 00 00 01 00-00 00 15 00 06 01 00 1b |...%.... ........|
0010 00 01 02 00 1c 00 01 03-00 1d 00 00 ff 0a 00 0f |........ ........|
0020 a0 00 00 02 00 - |.....|
login.c:1057:detected flag 2
login.c:782:quietly sending TDS 7+ login packet
token.c:328:tds_process_login_tokens()
net.c:555:Received header
0000 04 01 00 72 00 51 01 00- |...r.Q..|
net.c:609:Received packet
0000 04 01 00 72 00 51 01 00-aa 5e 00 18 48 00 00 01 |...r.Q.. .^..H...|
0010 0e 1d 00 4c 00 6f 00 67-00 69 00 6e 00 20 00 66 |...L.o.g .i.n. .f|
0020 00 61 00 69 00 6c 00 65-00 64 00 20 00 66 00 6f |.a.i.l.e .d. .f.o|
0030 00 72 00 20 00 75 00 73-00 65 00 72 00 20 00 27 |.r. .u.s .e.r. .'|
0040 00 74 00 73 00 6d 00 76-00 27 00 2e 00 0c 4d 00 |.t.s.m.v .'....M.|
0050 43 00 53 00 2d 00 44 00-41 00 54 00 41 00 42 00 |C.S.-.D. A.T.A.B.|
0060 41 00 53 00 45 00 00 01-00 fd 02 00 00 00 00 00 |A.S.E... ........|
0070 00 00 - |..|
token.c:337:looking for login token, got aa(ERROR)
token.c:122:tds_process_default_tokens() marker is aa(ERROR)
token.c:2588:tds_process_msg() reading message 18456 from server
token.c:2661:tds_process_msg() calling client msg handler
dbutil.c:85:_dblib_handle_info_message(0x14e2e30, 0x1391b70, 0x7fff8b047e40)
dbutil.c:86:msgno 18456: "Login failed for user 'xxx'."
token.c:2674:tds_process_msg() returning TDS_SUCCEED
token.c:337:looking for login token, got fd(DONE)
token.c:122:tds_process_default_tokens() marker is fd(DONE)
token.c:2339:tds_process_end: more_results = 0
was_cancelled = 0
error = 1
done_count_valid = 0
token.c:2355:tds_process_end() state set to TDS_IDLE
token.c:2370: rows_affected = 0
token.c:438:tds_process_login_tokens() returning TDS_FAIL
login.c:466:login packet accepted
util.c:156:Changed query state from IDLE to DEAD
util.c:331:tdserror(0x14e2e30, 0x1391b70, 20002, 0)
dblib.c:7929:dbperror(0x1383c70, 20002, 0)
dblib.c:7981:20002: "Adaptive Server connection failed"
dblib.c:8002:"Adaptive Server connection failed", client returns 2 (INT_CANCEL)
util.c:361:tdserror: client library returned TDS_INT_CANCEL(2)
util.c:384:tdserror: returning TDS_INT_CANCEL(2)
dblib.c:1443:dbclose(0x1383c70)
dblib.c:258:dblib_del_connection(0x7fa462faf540, 0x1391b70)
mem.c:615:tds_free_all_results()
dblib.c:305:dblib_release_tds_ctx(1)
dblib.c:5882:dbfreebuf(0x1383c70)
dblib.c:739:dbloginfree(0x1533a40)
なぜこれが機能しないのか、私は完全に迷っています。どんな助けでも大歓迎です。
私も同じ問題に直面しました。幸いなことに、私は何が悪いのかを見つけました。私のマシンには2つの異なるバージョンのFreeTDSがありました。私はそれらの1つ(v 0.91)を次の方法でインストールしました:
Sudo apt-get install freetds-dev
後で、それが最後のバージョンではないことがわかり、freetds.orgからFreetdsのtarファイルをダウンロードしました。 tsql-Cを実行したとき。それは正しいパスを示し、私はそのfreetds.confを正しく操作しました。環境変数を変更すると( http://www.freetds.org/userguide/envvar.htm )、データベースに接続できました。ただし、Pymssqlで接続しようとするたびに、エラーが発生しました。
最後に、ログファイルを調べたところ、Pythonは古いバージョン(v 0.91)を使用しているが、最後のバージョンはバージョン0.95であることがわかりました。
>>> import os
>>> os.environ['TDSDUMP'] = 'stdout'
>>>
>>> import pymssql
>>> conn = pymssql.connect(server="sqlserverhost")
そこで、バージョン0.91を次のように削除しました。
Sudo apt-get purge freetds-common
pymssqlは正しい構成で正しいバージョンに接続されています。
それはあなたにも役立つかもしれません。
pip install pymssql
を介してインストールした場合、暗号化をサポートしないビルド済みのOS固有のバイナリホイールがインストールされたため、同じ問題に直面しました。
これは、特定のバージョンのfreetdsをインストールしたとしても、使用されると思っていたものです。代わりにpip install --no-binary pymssql pymssql
を使用してインストールすると、機能するインストールが提供されました。
データベース接続を暗号化する場合は、最初にfreetdsをビルド/インストールしてから、ここで説明するようにpymssqlをインストールする必要があります。
この場合、暗号化されていないトラフィックにサイレントにフォールバックしないように、freetds.confファイルで「request」ではなく「require」を指定することを強くお勧めします。 tcpdump -A
を使用してSQLキーワードをgrepすると、トラフィックが本当に暗号化されているかどうかを判断するのに役立ちます。
pymssqlドキュメントの新しい注意事項に従ってください。Azureはユーザー部分を処理する必要があります。それはとても奇妙ですが、うまくいきました。 mssqlウェアハウスはlinux/macでの作業を非常に困難にします。
http://pymssql.org/en/latest/Azure.html
重要:関連するconnect()呼び出しのユーザーパラメーターに[email protected]を使用しないでください。代わりに、短いusername @serverフォームを使用する必要があります。