Bug #13736 "Network error IOException: Connection refused: connect"
Submitted: 4 Oct 2005 11:12 Modified: 26 Oct 2005 22:16
Reporter: Alexey Rusakov Email Updates:
Status: Can't repeat Impact on me:
None 
Category:MySQL Migration Toolkit Severity:S3 (Non-critical)
Version:1.0.18 rc OS:Windows (Windows XP/SP2)
Assigned to: CPU Architecture:Any

[4 Oct 2005 11:12] Alexey Rusakov 
Description:
MySQL migration toolkit fails to connect to the local unnamed MSSQL 2000 server with the following error: "Network error IOException: Connection refused: connect".

How to repeat:
Start the migration toolkit, and set up the connection to the local MS SQL server instance and try to fetch a list of tables using the [...] button, or proceed to the transfet screen so that migration toolkit tries to connect to the ms sql server instance.

Installing MS SQL 2000 SP4 doesn't help, tcp/ip and named pipes are enabled in sql server.

MS SQL Server client tools are able to connect to the server using the same credentials.

Suggested fix:
Manually specify the connection string to enable named pipes in jtds driver:
jdbc:jtds:sqlserver://127.0.0.1;user=user;password=password;namedPipe=true

It might also be necessary to restart the Migration Toolkit application
[4 Oct 2005 11:15] Alexey Rusakov 
Relevant posts:
http://forums.mysql.com/read.php?104,38514,47739
http://www.alexeyrusakov.com/sitecoreblog/2005/09/30/MySQL+Migration+Toolkit.aspx
[4 Oct 2005 13:46] Valeriy Kravchuk 
Thank you for a bug report. Please, check is it the same problem as reported already http://bugs.mysql.com/bug.php?id=13701. Sound similar for me.
[4 Oct 2005 14:31] Alexey Rusakov 
I've read through that bug before submitting mine.

Although they might look similar,  I think that the reason of the error is completely different: in my case jtdc driver was not able to connect to the ms sql server instance at all, hence the exception: "connection refused".

I don't think it is related to the collation problem in any way.
[5 Oct 2005 4:45] Jorge del Conde 
This problem is different than the one reported in #13701 because the one in 13701 is SQL_Latin1_General_CP1_CI_AS charset dependent.
[26 Oct 2005 22:16] Jorge del Conde 
I was unable to reproduce this bug using 1.0.20