Db lib error message 20002 severity 9

From pav…@fairsetup.com on January 16, 2013 13:08:02

READ FIRST Please (and then delete): * Support requests should be posted here (not reported as bugs): http://groups.google.com/group/pymssql * 1.x branch of pymssql is no longer supported, please don’t report bugs for it What steps will reproduce the problem? 1.I am trying to connect MS SQL server as below:
import pymssql
db = pymssql.connect(host=’xxx’,user=’xxx’,password=’xxx’,database=’xxx’)

What do you see?
I am getting the following error:

Traceback (most recent call last): File «XXX.py», line 2, in conn = pymssql.connect(host = ‘XXX.com’, user = ‘xxx’, password = ‘xxx’, database = ‘xxx’) File «pymssql.pyx», line 556, in pymssql.connect (pymssql.c:7990) raise OperationalError(e[0]) OperationalError: (20017, ‘xa0xffxafx02x90_x8dx02Lxd6xa7x02xdaxad;DB-Lib error message 20017, severity 9:nUnexpected EOF from the servernDB-Lib error message 20002, severity 9:nAdaptive Server connection failedn’) What version of the product are you using? On what operating system? SQL Server 2012 database running on Windows Server 2008 Please provide any additional information below.

Original issue: http://code.google.com/p/pymssql/issues/detail?id=110

I am trying to use FreeTDS to connect from a Linux server (RHEL v7) to a separate server running MS SQL Server 2014. However, when attempting to connect with tsql I get the following errors (error message differs depending on whether I include username and password):

$ tsql -S MYSERVER
locale is "en_US.UTF-8"
locale charset is "UTF-8"
using default charset "UTF-8"
Error 20002 (severity 9):
        Adaptive Server connection failed
There was a problem connecting to the server
$ tsql -S MYSERVER -U myusername -P mypassword
locale is "en_US.UTF-8"
locale charset is "UTF-8"
using default charset "UTF-8"
Error 20017 (severity 9):
        Unexpected EOF from the server
Error 20002 (severity 9):
        Adaptive Server connection failed
There was a problem connecting to the server

Additionally, running tsql -LH gives no output:

$ tsql -LH MYSERVER
$

I don’t believe the issue is with a firewall or anything else on the SQL Server side, because:

1. I am able to telnet to the server:

   $ telnet my.server.address 1433
   Trying 11.22.33.444...
   Connected to my.server.address.
   

2. And, I can successfully connect to the SQL Server via ODBC from a (Windows) laptop, via the ODBC Data Source Administrator utility.

Contents of my /etc/freetds.conf:

[global]
  tds version = 7.0
; tds version = 4.2
...
[MYSERVER]
  host = my.server.address
  port = 1433
  tds version = 7.0

Contents of TDSDUMP log file after running tsql -S MYSERVER:

log.c:167:Starting log file for FreeTDS 0.95.19
  on 2015-11-18 10:02:20 with debug flags 0x4fff.
iconv.c:328:tds_iconv_open(0x1c53d90, UTF-8)
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:346:setting up conversions for client charset "UTF-8"
iconv.c:348:preparing iconv for "UTF-8" <-> "UCS-2LE" conversion
iconv.c:395:preparing iconv for "ISO-8859-1" <-> "UCS-2LE" conversion
iconv.c:400:tds_iconv_open: done
net.c:202:Connecting to 11.22.33.444 port 1433 (TDS version 7.0)
net.c:274:tds_open_socket: connect(2) returned "Operation now in progress"
net.c:313:tds_open_socket() succeeded
util.c:165:Changed query state from DEAD to IDLE
login.c:797:using GSS authentication
gssapi.c:218:using kerberos name MSSQLSvc/my.server.address:1433
gssapi.c:230:gss_import_name: GSS_S_COMPLETE: gss_import_name completed successfully.
gssapi.c:318:gss_init_sec_context: actual mechanism at 0x(nil)
gssapi.c:334:gss_init_sec_context: min_stat 2529639136 "Unknown error -1765328160"
gssapi.c:374:gss_init_sec_context: GSS_S_FAILURE: The routine failed for reasons that are not defined at the GSS level.
login.c:472:login packet rejected
query.c:3769:tds_disconnect()
util.c:165:Changed query state from IDLE to DEAD
util.c:322:tdserror(0x1c53ca0, 0x1c53d90, 20002, 0)
util.c:352:tdserror: client library returned TDS_INT_CANCEL(2)
util.c:375:tdserror: returning TDS_INT_CANCEL(2)
mem.c:648:tds_free_all_results()

Symptoms

• Migration of a subscription fails with the following error:

  PLESK_ERROR: Failed to deploy databases of subscription ‘example.com’
  Migration tools tried to perform operation in 3 attempts: Failed to execute SQL query: DB-Lib error message 20017, severity 9:
  Unexpected EOF from the server (localhost:1433)
  DB-Lib error message 20002, severity 9:
  Adaptive Server connection failed (localhost:1433)

• In migration log %plesk_dir%varmodulespanel-migratorsessionsYYYMMDDhhmmssdebug.log there are errors about failed connection via particular TLS versions:

  URLError: <urlopen error [Errno 10054] An existing connection was forcibly closed by the remote host>
  Connecting using TLSv1.1

  ---

  URLError: <urlopen error [Errno 10054] An existing connection was forcibly closed by the remote host>
  Connecting using TLSv1.2

Cause

Due to Plesk MIgrator bug PMT-4793, TLSv1.0 support is required, but it is disabled in the registry. The bug will be fixed in future extension updates.

Resolution

As a workaround:

1. Connect to the destination server via RDP;

2. Go to Start > Run > type regedit to open Windows Registry;

3. Enable TLSv1.0 by updating (or creating) the following registry entry:

   • Name with full path: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0ServerEnabled
   • Type: REG_DWORD
   • Value data: 1

4. Restart the MSSQL server service at Start > Run > type services.msc > right click SQL Server > Restart.

   Note: TLSv1.0 can be disabled again by reverting/setting the Value data to 0 and restarting the SQL Server.

5. Log into Plesk;

6. Resync the subscription Tools & Settings > Migration & Transfer Manager > 203.0.113.2 > example.com > Re-sync.