I'm using FreeTDS 0.91 to connect to a remote MSSQL server but all attempts have borne no fruit thus far.
Upon doing a tsql command on my Unix, I get the following error:
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
The freetds.log has the following in it:
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()
Does this at all seem like it could be an issue with the SQL server, or am I installing or have configured FreeTDS wrong?
So lost. Please help.
When I connect to the server via telnet, this is the response I get back:
Trying 70.70.218.13...
Connected to 70.70.218.13.
Escape character is '^]'.
^^
Connection closed by foreign host.
Would this mean that the telnet connection to the host was successful?
The SQL database is run on a windows server. Would connecting to the Windows server (just like you would through remote desktop) be the right sort of values to use for the hostname and port? Or would I have to find a direct hostname to the SQL server on the windows server?
The default location of freetds. conf is determined by the sysconfdir option of configure. If you don't specify anything, configure's default sysconfdir is /usr/local/etc. In addition, FreeTDS will look for a file .
Khan.
I just encountered this same situation. And I resolved this problem by adding a .freetds.conf to my home,
[global]
# TDS protocol version
tds version = 7.0
And I know this is exactly the answer to most FreeTDS connect problems.
And this method is also provided by @Michael Berkowski.
With apologies for the five year necromancy, it appears that this error will also occur when tsql successfully connects to an open port, but the listener is some service other than SQL Server. It seems FreeTDS does not try to check if it's talking to a service other than SQL Server on login, so the error messages are cryptic. (In my case, I was using the port number for Remote Desktop.)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With