

#ANDROID SQL SERVER CLIENT DRIVER#
Version 11 (which is what my ODBC driver is pegged to) exhibits this behavior, while the latest v13 does not. Interestingly the behavior would vary depending on the version of the SQL Server driver. Which seems to suggest there's some sort of protocol discovery problem where the driver is trying to use TCP/IP first, and failing to get a connection before trying the other protocols. database=webstore integrated security=yes") database=webstore integrated security=yes")Ĭhanging the connection string to explicitly specify the protocol however fixes the issue: losql = CREATEOBJECT("wwSql") There connecting to SQL server like this with only Named Pipes enabled: losql = CREATEOBJECT("wwSql") In particular I ran into this problem with a FoxPro application which means it's using the SQL Server ODBC driver. As well it should be.Īnybody have any ideas why Named Pipes are so slow for SQL connections? It almost seems like a fixed delay because it's so consistent across several different machines.Īfter a bit more digging it appears that the problem isn't the Named Pipe Connection itself, but something related to the protocol discovery. Each machine I've removed TCP/IP from takes about 2 seconds to connect with either Named Pipes or Shared Memory, while with TCP/IP Connections enabled connections are nearly instant on a local machine. I'm pretty sure that I've used Named Pipes in the past and didn't see this type of slow connection times, but I've verified this on several machines so it's not just a fluke with my new dev box. Just for good measure I also turned off the other two, but that's optional. Once you're there navigate to the Sql Server Network configuration and enable TCP/IP: Add the Sql Server Configuration snap-in (ctrl-m -> Sql Server).With recent versions of SQL Server it looks like Microsoft is no longer installing shortcuts for the SQL Server Configuration Manager, so I had to launch it using the mmc.exe and adding the snap-in: To enable TCP/IP we'll need to set the protocols in the Sql Server Configuration Manager.

I'm not sure why Named Pipes (or is it Shared Memory) are so dreadfully slow - if that's the case why would you ever use it? Enabling TCP/IP It turns out that a new SQL Server installation does not enable TCP/IP by default and if you're using a standard connection string it uses named pipes which on this machine at least results in very slow connection times with what looks like a 2 second delay for every connection. This is a local dev machine and I have a local SQL Server Developer installed. It's not only the first request, but any connection request including what should otherwise be pooled connections.Īs you might imagine in Web applications that's a major problem even on a dev machine - it makes for some excruciatingly slow Web requests. Everytime I make a new SQL Connection there's a 2 second delay for the connection to occur. just fought with a small issue where connections to SQL Server were very slow on a new development box.
