SQL Network Interfaces, error: 50 - Local Database

Question

EDIT: One important detail that I original left out (because I didn't know it was important) is that we were running these sites in full IIS, not from IIS Express.

---

We're trying to setup local dev environments for Kentico CMS that will add our local machines to our current synchronization chain of Dev --> Staging --> Prod (so we'll wind up with Locals --> Dev --> Staging --> Prod).

We copied our Dev DB to our local machines onto the (localdb)\v11.0 instance of SQL Server, but we're running into an issue on everyone's computers except mine.

Here's the error we're getting:

The application could not connect to the database, please check the connection string in the web.config file and SQL server availability.

Original error:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 50 - Local Database Runtime error occurred. The specified LocalDB instance does not exist. )

I've tried a ton of suggestions from other SO answers and other websites to figure out why we're getting this error (and why it's not happening on my machine), but no luck. We can connect to (localdb)\v11.0 in SSMS but we cannot connect to it through VS (same error). Also, when we open Sql Server Config Manager, we're not seeing any listings for SQL Server Services. Any ideas?

Answer 1

1. Make sure you have .NET Framework 4.0.2+ installed
2. Set up your AppPool to run under the NetworkService account.

3. Create a login for that account in your db.

   USE [master]; CREATE LOGIN [NT AUTHORITY\NETWORK SERVICE] FROM WINDOWS; EXEC sp_addsrvrolemember N'NT AUTHORITY\NETWORK SERVICE', SYSADMIN;

4. Share your instance with all users by running SqlLocalDB share Kentico KenticoShared

5. Use connection string in the following format:

<add name="CMSConnectionString" connectionString="Data Source=(localdb)\.\KenticoShared;Initial Catalog=KenticoDB;Integrated Security=True;Connect Timeout=60" />

6. If it doesn't help use a named pipe:

<add key="CMSConnectionString" value="Persist Security Info=False;Integrated Security=SSPI;database=KenticoDB;server=np:\\.\pipe\LOCALDB#D2BA6590\tsql\query;Current Language=English;Connection Timeout=120;" />

Notes:

1. the exact name of the NetworkService account on your machine can be determined by running following C#

var ns = new SecurityIdentifier(WellKnownSidType.NetworkServiceSid, null).Translate(typeof(NTAccount)).ToString()

2. named pipe can be determined by running this in CMD: SqlLocalDB info KenticoShared
3. don't forget to run your instance SqlLocalDB start KenticoShared

Answer 2

See this post as this solved my problem: These two posts on Using LocalDB with Full IIS should give you more information. Especially the second part seems relevant, but the first one contains some context as well.

1. Part 1: User Profile
2. Part 2: Instance Ownership

Credit: IIS connecting to LocalDB

Answer 3

Seems a little obscure, but have you looked at http://support.microsoft.com/kb/941823 , "Some or all SQL Server 2005 services are not listed in SQL Server Configuration Manager..."?

And there are generally two things that get in the way of connecting to SQL Server from an application even though you can connect using Management Studio. First, you should make sure that TCP is enabled on the instance, http://msdn.microsoft.com/en-us/library/bb909712(v=vs.90).aspx . Second, since you're connecting to a named instance, which I'm assuming is not the default instance running on the standard port, you need to make sure that the SQL Server Browser service is running, http://technet.microsoft.com/en-us/library/ms165734(v=sql.90).aspx . This is what redirects applications to a non standard port without having to specify the port directly. The reason Management Studio can get past these is that it can connect through named pipes and skip TCP altogether.