none
wswp.exe accessing ms-sql on 1433 when server=(local) on conn string RRS feed

  • Question

  • Hello everyone,
    I have the sql connection string configured in my web application as
    data source=(local); provider=sqloledb.1; user id=<<user id>>; password=<<password>>; database=<<database>>

    My understanding is that when (local) is used, the connection method will fall to shared memory / named pipes. I have names pipes and TCP/IP enabled in the configuration manager.

    My machine is also running Comodo Firewall .

    Now this is what is happening. When I try to access the asp.net application, I get a component exception in comodo firewall that indicates w3wp.exe is trying to access the sql server via the machine's IP over port 1433. This happens when I try to load the application in the browser.

    What I dont understand is that when (local) is configured, it should only access thru shared memory / named pipes. Why is it trying to connect thru TCP port. Is this because I have the sql username and password? My SQL server is configured for mixed mode authentication.

    Thanks
    RK

    Wednesday, December 19, 2007 11:12 PM

Answers

  • Hi Oleg,

       Thanks for your replies. I have not been able to login to the forums during the daytime for the past couple of days.

    Yes, I did read a great post by Jon Galloway on how to force the protocol on the connection string at http://weblogs.asp.net/jgalloway/archive/2007/02/24/sql-force-the-protocol-tcp-named-pipes-etc-in-your-connection-string.aspx and used it to force the named pipes (np). Changing the protocol order in SQL Server configuration manager did not help as you had pointed.

     

    I will change the protocol to SQL server native client. This issue got me puzzled and led me off track. I will also look at your suggestions regarding the registry. Its great to know about these things.

     

    Thanks for taking your time to help me

    Ganapat

    Saturday, December 22, 2007 3:36 AM

All replies

  •  

    Hello ganapat,

     

    Username/password in connection string do not influence connection approach. Make sure you have the correct order of the protocols in the "SQL Native Client Configuration" -> "Client Protocols" section of the configuration of the Sql Server Configuration Manager. If it's critical for you to connect via named piped only you can disable the TCP/IP protocol for the server.

    I'm currently investigating your problem. Please check this thread for updates.

    Thanks!
    Thursday, December 20, 2007 2:03 AM
    Moderator
  •  

    Ganapat,

     

    I still don't have an answer why SQLOLEDB provider connects to the TCP port even if it can connect via named pipes however I have a few suggestions for you.

     

    I would recommed using SqlClient instead of the SQLOLEDB provider. Modify your web.config to look like this:

      <connectionStrings>
        <add name="<connection string name>" connectionString="<your connection string>"
          providerName="System.Data.SqlClient" />
      </connectionStrings>
    You can compare SqlClient with SQLOLEDB here http://msdn2.microsoft.com/en-us/library/a6cd7c08(VS.71).aspx 

    If SqlClient doesn't work for you please use SQLNCLI or SQLNCLI10 for provider property. These stand for SQL Server Native Client.

     

    You can also specify the protocol prefix in your connection string like this "data source=np:localhost; provider=sqloledb.1; ". From the connection string parser point of view data source values of "(local)", "localhost" and "." are the same. The list of protocol prefixes you can use in your connection string:

    • tcp - TCP/IP
    • np - Named Pipes
    • sm - Shared Memory
    • via - VIA

    Please let me know if this information helped you or whether you need further clarification.

    Thank you!

    Thursday, December 20, 2007 11:14 PM
    Moderator
  • Now I have an answer to your original question. SQL Server Native Client and SQLOLEDB use different protocol sequences.

     

    SQLNCLI10 stores the protocol sequence here:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SNI10.0\ProtocolOrder

     

    SQLOLEDB operates with the connection sequence from:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\SuperSocketNetLib\ProtocolOrder

    OR

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\SuperSocketNetLib\ProtocolOrder

     

    Please also pay attention to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\SuperSocketNetLib\LastConnect which contains information about the last successfull connection attempt.

     

    Thursday, December 20, 2007 11:53 PM
    Moderator
  • Hi Oleg,

       Thanks for your replies. I have not been able to login to the forums during the daytime for the past couple of days.

    Yes, I did read a great post by Jon Galloway on how to force the protocol on the connection string at http://weblogs.asp.net/jgalloway/archive/2007/02/24/sql-force-the-protocol-tcp-named-pipes-etc-in-your-connection-string.aspx and used it to force the named pipes (np). Changing the protocol order in SQL Server configuration manager did not help as you had pointed.

     

    I will change the protocol to SQL server native client. This issue got me puzzled and led me off track. I will also look at your suggestions regarding the registry. Its great to know about these things.

     

    Thanks for taking your time to help me

    Ganapat

    Saturday, December 22, 2007 3:36 AM