Как я могу обойти слишком длинное имя для LOGINREC в pymssql без изменения имени пользователя

Я пытаюсь использовать pymssql для подключения к клиентской базе данных, но до сих пор не смог добиться успеха. Я считаю, что корень проблемы заключается в этой записи в трассировке стека моего TDSDUMP:

dblib.c:761:dbsetlname(0x1ac3e10, <username>@<servername>.database.windows.net, 2) dblib.c:7929:dbperror((nil), 20042, 0) dblib.c:7981:20042: "Name too long for LOGINREC field"

Одна проблема заключается в том, что <servername>.database.windows.net уже превышает ограничение строки (которое, согласно этому, кажется равным 30: Как использовать драйвер PHP dblib PDO с длинными именами пользователей? / SQLSTATE[HY000] Имя слишком длинное для поля LOGINREC (уровень важности 2).

Я также попытался исключить часть @<servername>.database.windows.net в записи имени пользователя только для получения следующей ошибки:

msgno 40532: "Cannot open server "1433D" requested by the login. The login failed."

Согласно https://github.com/pymssql/pymssql/issues/330 @<servername> часть запрашивается сервером.

Итак, в этот момент я попытался сделать следующее:

user = username + "@{}".format(server)
user = user[:30]

И я получил следующую информацию (что было небольшим улучшением, но все же не идеальным, учитывая, что я все еще не мог установить соединение):

"Cannot open server "<server_name minus the last 6 characters>" requested by the login. The login failed."

Если возможно, я бы предпочел передать какой-либо параметр методу подключения pymssql, который переопределит это ограничение на количество символов или сделает что-то, чтобы добавить сервер к имени пользователя на бэкэнде после вызова dbsetlname только для <username> без части @<servername>. Есть ли у кого-нибудь какие-либо рекомендации (опять же предпочтение состоит в том, чтобы не просить клиента изменить наше имя пользователя, но нам, возможно, придется прибегнуть к этому или попытаться использовать pyodbc, если нет другого варианта).

Вот несколько способов подключения, которые я пробовал:

conn = pymssql.connect(
host=host,
database=database,
user=username,
password=password,
port=int(port) # this is 1433
)

conn = pymssql.connect(
host=host,
database=database,
user=username + '@{}'.format(servername),
password=password,
port=int(port) # this is 1433
)



conn = pymssql.connect(
server=<servername>.database.windows.net,
database=database,
user=username,
password=password,
port=int(port) # this is 1433
)

Заранее спасибо за любую помощь/совет, который вы можете предложить!


python-2.7 pymssql freetds
person JPope2014    schedule 06.03.2017    source источник
comment
Можете ли вы включить метод pymssql.connect(), который вы используете для подключения?   -  person FlipperPA    schedule 07.03.2017
comment
Добавлено по просьбе!   -  person JPope2014    schedule 07.03.2017
comment
Да, я никогда не видел, чтобы SQL Server требовал этого. Я не уверен, что вам нужно что-то конкретное для SQL Server; возможно, попробуйте pyodbc с FreeTDS вместо pymssql с FreeTDS? Это стек, который я использую, и теперь он официально поддерживается Microsoft.   -  person FlipperPA    schedule 07.03.2017
comment
@FlipperPA - я знаю, что Microsoft теперь официально поддерживает pyodbc, но я просто предположил, что это было связано с их собственным драйвером ODBC, а не с FreeTDS_ODBC. Я ошибаюсь? Поддерживает ли Microsoft официально FreeTDS_ODBC?   -  person Gord Thompson    schedule 10.03.2017
comment
Вы пытались явно указать версию 7.3 протокола TDS, чтобы узнать, поможет ли это?   -  person Gord Thompson    schedule 10.03.2017
comment
@GordThompson, да, я на самом деле пробовал 7.3, 7.0, 7.1, что бы ни было по умолчанию, а также 8.0 :/. Кажется странным, что pymssql накладывает ограничение на длину на стороне клиента, которое является более жестким, чем то, что налагается самим сервером. Я думаю, что теоретически я мог бы проследить трассировку стека для ошибки обратно в C и изменить ее, а затем перестроить pymssql? Но мы действительно хотели бы не вносить никаких изменений в базовый пакет, если мы можем помочь. Возможно, как вы, ребята, говорите, pymssql с FreeTDS просто не подходит для этой работы.   -  person JPope2014    schedule 10.03.2017
comment
Кажется странным, что pymssql накладывает ограничение на длину – Этот комментарий на GitHub предполагает, что это может быть связано с особым API, который pymssql использует для работы с FreeTDS.   -  person Gord Thompson    schedule 10.03.2017
comment
Согласно сообщению в блоге Microsoft, они будут поддерживать pyodbc и django-pyodbc-azure с SQL Server. Я до сих пор использую FreeTDS с pyodbc, и он работает очень хорошо.   -  person FlipperPA    schedule 10.03.2017
comment
Спасибо Флиппер и Горд за вашу помощь в этом. Когда клиент сократил имя пользователя, мы все еще не могли подключиться из-за проблемы с шифрованием и проблемы с pymssql (неправильная версия FreeTDS и не могла ее переопределить), поэтому в конце концов я использовал pyodbc. На самом деле это сработало очень хорошо, единственная усугубляющая часть заключается в том, что нам нужно распространять файл odbc.ini с нашей конфигурацией драйвера, чтобы быть уверенным, что драйвер FreeTDS доступен, но эта проблема очень мала, особенно учитывая проблемы, которые мы использовали pymssql.   -  person JPope2014    schedule 27.03.2017

Ответы (1)


arrow_upward
0
arrow_downward

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

Если вы используете проверку подлинности SQL Server, попробуйте следующее:

conn = pymssql.connect(
    server="<servername>.database.windows.net",
    port=1433,
    user="username",
    password="password",
    database="dbname"
)

Если вы используете аутентификацию Windows:

conn = pymssql.connect(
    server="<servername>.database.windows.net",
    port=1433,
    user="DOMAIN\USERNAME",
    password="password",
    database="dbname"
)

Вы пробовали какой-либо из этих способов подключения?

person FlipperPA    schedule 07.03.2017
comment
Эй, я ценю это предложение, но я уже пробовал это вскоре после того, как задал этот вопрос. К сожалению, он все же вернул 1433D. - person JPope2014; 07.03.2017