Bugzilla – Bug 320311
Getting SQL Exception when connecting to SQL Server Database.
Last modified: 2008-09-08 19:31:18 UTC
---- Reported by boinc_spy@telus.net 2006-02-11 17:59:08 MST ---- Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: Steps to reproduce the problem: 1. Execute simple connection to SQL Server database 2. Get System.Data.SqlClient.SqlException: SQL Server does not exisit. Code Fragment. string connectString= "server=172.16.0.186\\BoincSpy;User ID=bob;Password=password;Initial Catalog=BoincSpy"; SqlConnection databaseConnection = new SqlConnection(connectString); databaseConnection.Open(); Actual Results: Get exception Expected Results: Not to get one. How often does this happen? Everytime Additional Information: 1. Sql Connection string works in a Windows .net 2.0 implementation. 2. Data does return back from Server. Run EtherReal analyzer in it. 3. If I comment the following Code fragment in SqlConnection.DiscoverTcpPort the program will not get throw an exception. if (!Active) return -1; // Error bool result; result = Client.Poll (100, SelectMode.SelectRead); if (result == false) return -1; // Error if (Client.Available <= 0) return -1; // Error ---- Additional Comments From tsenganal@novell.com 2006-02-13 04:14:08 MST ---- Hi.. can u try the following steps: 1. make sure that port 1434 is not blocked on the server.. mono, needs the udp port 1434 to connect to the named instances .. Try connecting after opening up 1434.. it shud work.. 2. If the above step doesnt work, try passing the port number ,at which the instance is listening, in the connection string.. Ex : "server=<host>,<port>;.." pls, let me know the results.. ---- Additional Comments From boinc_spy@telus.net 2006-02-16 22:49:04 MST ---- Have verified: 1) No ports are being blocked by server. 2) I have tried putting the port # with same result. As I have indicated, the initial connection to server appears to send and recieve packets. See below. 19:39:07.978930 IP 192.168.168.22.49602 > 172.16.0.186.ms-sql-m: S 1763844837:1763844837(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 1071189050 0> 0x0000: 4500 003c 3086 4000 4006 f4ac c0a8 a816 E..<0.@.@....... 0x0010: ac10 00ba c1c2 059a 6922 22e5 0000 0000 ........i""..... 0x0020: a002 ffff 15b8 0000 0204 05b4 0103 0300 ................ 0x0030: 0101 080a 3fd9 0c3a 0000 0000 ....?..:.... 19:39:08.252488 IP 172.16.0.186.ms-sql-m > 192.168.168.22.49602: R 0:0(0) ack 1763844838 win 0 0x0000: 4500 0028 f36e 0000 7e06 33d8 ac10 00ba E.. (.n..~.3..... 0x0010: c0a8 a816 059a c1c2 0000 0000 6922 22e6 ............i"". 0x0020: 5014 0000 46e2 0000 0000 0000 0000 4ccb P...F.........L. 0x0030: bdd3 ---- Additional Comments From boinc_spy@telus.net 2006-02-16 22:57:48 MST ---- One more item. Version of SQL Server connecting to is 2005. ---- Additional Comments From monodanmorg@yahoo.com 2006-08-07 13:29:52 MST ---- Is TCP/IP enabled for the instance? By default, Microsoft SQL Server 2005 only has shared memory enabled. TCP/IP is disabled. Also, make sure your firewall is not block mono.exe nor your application.exe Add this to your connection string when running on .NET: network library=dbmssocn If you get a SqlException after adding this connection parameter, then the problem is not with mono. See what you get. ---- Additional Comments From boinc_spy@telus.net 2006-11-25 03:31:25 MST ---- Further information: If I Connect to a SQL server that is on a LAN no issue, If I connect to a SQL server over a VPN LAN the connection fails. ---- Additional Comments From boinc_spy@telus.net 2006-11-25 03:34:06 MST ---- Previous post should have read. If I connect to a SQL server over a VPN WAN the connection fails. Unknown bug field "cf_op_sys_details" encountered while moving bug <cf_op_sys_details>10.4 and Fedora FC4</cf_op_sys_details>
Is this still valid? Can you try 2.0 or trunk?
This appears to be fixed by the following comment made on 2008-04-08. 2008-04-08 Marek Habersack <mhabersack@novell.com> * SqlConnection.cs: TCP port discovery via UDP port 1434 should honor the timeout specified in the connection string (or the default one). In some environments 100 microseconds might not be enough to discover the port. If I was connecting over a LAN line 100 microseconds would be not enough time. I do not know if this is the 1.9.1 branch... will compile from source code and verify...
This issue has been fixed with the latest branch from SVN... Can be closed....