Блог

Я использую FreeTDS 0.91 для подключения к удаленному серверу MSSQL, но все попытки пока не принесли результатов.

После выполнения команды tsql в моем Unix я получаю следующую ошибку:

   locale is "en_US.UTF-8"
  locale charset is "UTF-8"
  using default charset "UTF-8"
  Error 20004 (severity 9)
  Read from the server failed
  OS error 104, "Connection reset by peer"
  Error 20002 (severity 9)
  Adaptive Server connection failed
  There was a problem connecting to the server
  

FreeTDS.в журнале содержится следующее:

 16:05:49.144905 20207 (log.c:196):Starting log file for FreeTDS 0.91
  on 2011-09-28 16:05:49 with debug flags 0xffff.
  16:05:49.145281 20207 (iconv.c:330):tds_iconv_open(0x3d29320, UTF-8)
  16:05:49.145426 20207 (iconv.c:187):local name for ISO-8859-1 is ISO-8859-1
  16:05:49.145448 20207 (iconv.c:187):local name for UTF-8 is UTF-8
  16:05:49.145459 20207 (iconv.c:187):local name for UCS-2LE is UCS-2LE
  16:05:49.145469 20207 (iconv.c:187):local name for UCS-2BE is UCS-2BE
  16:05:49.145479 20207 (iconv.c:349):setting up conversions for client charset "UTF-8"
  16:05:49.145489 20207 (iconv.c:351):preparing iconv for "UTF-8" "UCS-2LE" conversion
  16:05:49.145508 20207 (iconv.c:391):preparing iconv for "ISO-8859-1" "UCS-2LE" conversion
  16:05:49.145533 20207 (iconv.c:394):tds_iconv_open: done
  16:05:49.145550 20207 (net.c:205):Connecting to 70.70.218.13 port 2600 (TDS version 7.0)
  16:05:49.145686 20207 (net.c:270):tds_open_socket: connect(2) returned "Operation now in progress"
  16:05:49.236008 20207 (net.c:310):tds_open_socket() succeeded
  16:05:49.236061 20207 (util.c:156):Changed query state from DEAD to IDLE
  16:05:49.236083 20207 (login.c:782):quietly sending TDS 7  login packet
  16:05:49.236173 20207 (token.c:328):tds_process_login_tokens()
  16:05:49.857930 20207 (util.c:331):tdserror(0x3d29080, 0x3d29320, 20004, 104)
  16:05:49.858072 20207 (util.c:361):tdserror: client library returned TDS_INT_CANCEL(2)
  16:05:49.858090 20207 (util.c:384):tdserror: returning TDS_INT_CANCEL(2)
  16:05:49.858114 20207 (util.c:156):Changed query state from IDLE to DEAD
  16:05:49.858137 20207 (token.c:337):looking for login token, got  0()
  16:05:49.858155 20207 (token.c:122):tds_process_default_tokens() marker is 0()
  16:05:49.858168 20207 (token.c:125):leaving tds_process_default_tokens() connection dead
  16:05:49.858179 20207 (login.c:466):login packet accepted
  16:05:49.858189 20207 (util.c:331):tdserror(0x3d29080, 0x3d29320, 20002, 0)
  16:05:49.858209 20207 (util.c:361):tdserror: client library returned TDS_INT_CANCEL(2)
  16:05:49.858220 20207 (util.c:384):tdserror: returning TDS_INT_CANCEL(2)
  16:05:49.858232 20207 (mem.c:615):tds_free_all_results()
  

Похоже ли, что это может быть проблемой с SQL server, или я устанавливаю или неправильно настроил FreeTDS?

Так что потеряно. Пожалуйста, помогите.

Когда я подключаюсь к серверу через telnet, это ответ, который я получаю обратно:

Попытка 70.70.218.13…
Подключен к 70.70.218.13.
Escape-символ — ‘^]’.
^^
Соединение закрыто внешним хостом.

Будет ли это означать, что подключение telnet к хосту было успешным?

База данных SQL запускается на сервере Windows. Будет ли подключение к Windows server (как и через удаленный рабочий стол) правильным типом значений для имени хоста и порта? Или мне нужно будет найти прямое имя хоста для SQL server на сервере Windows?

Хан.

Я только что столкнулся с такой же ситуацией. И я решил эту проблему, добавив файл .freetds.conf в свой домашний,

 [global]
    # TDS protocol version
    tds version = 7.0 
  

И я знаю, что это именно то, что нужно для решения большинства проблем с подключением к FreeTDS.

И этот метод также предоставлен @Michael Berkowski.

Принося извинения за пятилетнюю некромантию, похоже, что эта ошибка также будет возникать, когда tsql успешно подключается к открытому порту, но слушателем является какая-либо служба, отличная от SQL Server. Похоже, FreeTDS не пытается проверить, обращается ли он к службе, отличной от SQL Server, при входе в систему, поэтому сообщения об ошибках являются загадочными. (В моем случае я использовал номер порта для удаленного рабочего стола.)

Если вы не хотите создавать .freetds.conf , вы можете просто TDSVER вместо этого установить переменную среды (например, в Windows для подключения к SQL Server 2008 используйте TDS версии 7.3):

 set TDSVER=7.3
  

(для использования * nix export ).

См. http://www.freetds.org/userguide/envvar.htm для получения дополнительных переменных среды.

См. http://www.freetds.org/userguide/choosingtdsprotocol.htm для версий TDS различных СУБД

Вы также можете указать путь к файлу журнала, который может предоставить дополнительную информацию, установив переменную среды TDSDUMP , которая поможет устранить неполадки и покажет вам, где искать файлы конфигурации. например

 set TDSDUMP=C:tempfreetds.log
  

В моем случае установка переменной TDSDUMP выявила ошибку в журналах:

 iconv.c:346:setting up conversions for client charset "CP1252;LC_CTYPE=English_United States.1252;LC_MONETARY=C;LC_NUMERIC=C;LC_TIME=C"
iconv.c:348:preparing iconv for "CP1252;LC_CTYPE=English_United States.1252;LC_MONETARY=C;LC_NUMERIC=C;LC_TIME=C" <-> "UCS-2LE" conversion
iconv.c:423:tds_iconv_info_init: client charset name "-1" invalid
  

По-видимому, FreeTDS не проанализировал имя кодировки из строки «CP1252;LC_CTYPE=English_United States.1252;LC_MONETARY= C;LC_NUMERIC= C;LC_TIME= C»

Я создал .freetds.conf файл со следующим содержимым:

 [global]
    tds version = 7.3           # version 7.3 for MSSQL 2008
    client charset = UTF-8      # so that we can get unicode characters
  

И сохранил его C:WindowsSystem32configsystemprofileAppDataRoaming в соответствии с предложением файла журнала, что устранило проблему для меня.