I got the answer Now-
IPAddress will always create a TCP/IP connection from client to SQL Server instance. This will hold true even if you are connecting to the SQL Server running on Local machine [where the client is also running] and Shared Memory option of that SQL Server instance is enabled.
If you use a Server name [or local, localhost,period(.) etc.]in the connection string, SqlClient will first check if the instance is running on local machine, If Yes, then whether SQLServer Shared Memory is enabled, and if Yes too, then it will connect using shared Memory rather than using any other protocol like TCP/IP,Named Pipe etc. to connect to the server.
To test this I’ve done following-
I installed SQLExpress on my local machine.For SQlExpress, only the shared memory connection type on the local machine is accessible by default, although the user can explicitly turn on other supported protocols such as TCP/IP and Named Pipes.
I created a simple .Net Winform which connects to AdventureWorks DB to show data from SalesOrderHeader in a DataGridView [This is the simplest stuff I could have tried with :-)]
Everything worked fine as I was able to show table data onto my Grid.
My App.config had an entry for SQL Connection string which uses my machine name for data Source-
When I changed this connection string to use MYIPADDRESS instead of MYMACHINENAME, I got the error "provider: SQL Network Interfaces, error: 28 - Server doesn't support requested protocol".
I went to Surface Area Configuration tool to enable Remote connections with support to TCP/IP.
I restarted the SQL engine before running my application again and ..... Bingo! Everything starts working again.
This behaviour can be helpful while using replication, when both the main server and replication server are installed on the same machine.
I am not sure whether this can be true when connecting from .Net client to a Local Oracle DB with shared memory enabled, I need to try that. Once done I will post the results.

No comments:
Post a Comment