• SQL Server 2005 Express will not be suported on Windows 8.
• SQL Server Express is not supported on Windows on ARM.

Share Your Feedback

Please share your feedback with us! Just start a thread on SQL Express Forum, hit the "Email Author" button on this post, or file a Connect item!

Quick Recap

In the first post of this mini-series we said there are two properties of LocalDB causing problems when running under full IIS:

• LocalDB needs user profile to be loaded
• LocalDB instance is owned by a single user and private (by default)

We saw how to properly load the user profile, now it's time to tackle the problem of LocalDB instance ownership.

The Problem of the Private Instance

At the end of the previous post we left our Web Application in this state:

As we can see we are facing the following error:

System.Data.SqlClient.SqlException: Cannot open database "OldFashionedDB" requested by the login. The login failed.
Login failed for user 'IIS APPPOOL\ASP.NET v4.0'.

This time the error is quite clear. LocalDB was started and the Web Application was able to connect to it, but the connection was then terminated due to login failure. The ApplicationPoolIdentity account for the IIS application pool (in this case IIS APPPOOL\ASP.NET v4.0) couldn't login to LocalDB instance because the database specified in the connection string (OldFashionedDB) wasn't found. How odd, since connecting from Visual Studio with the same connection string succeeds!

(In this screenshot I am using SQL Server Object Explorer, which is introduced by SQL Server Data Tools. As you can see it adds SQL Server tools right inside Visual Studio 2010.)

How is it possible that Visual Studio connects to LocalDB just fine, while the connection from Web Application fails? In both cases the connection string is the following:

Data Source=(localdb)\v11.0;Initial Catalog=OldFashionedDB;Integrated Security=True

The answer is that there are two different LocalDB instances here. Unlike SQL Server Express instances, which are running as Windows services, LocalDB instances are running as user processes. When different Windows users are connecting to LocalDB, they will end up with different LocalDB processes started for each of them. When we connect to (localdb)\v11.0 from Visual Studio, a LocalDB instance is started for us and runs as our Windows account. But when Web Application, running in IIS as ApplicationPoolIdentity, is connecting to LocalDB, another LocalDB instance is started for it and is running as ApplicationPoolIdentity! In effect, even though both Visual Studio and Web Application are using the same LocalDB connection string, they are connecting to different LocalDB instances. Obviously the database created from Visual Studio on our LocalDB instance will not be available in Web Application's LocalDB instance.

A good analogy to this is My Documents folder in Windows. Say we open Visual Studio and create a file in our My Documents folder. Then we login to the same machine as a different user and go to My Documents folder again. We won't find the file there as My Documents of the second user and our My Documents are two different folders. Similarly LocalDB instances (localdb)\v11.0 owned by two different users are two different processes with two different sets of databases.

This is also the reason the Web Application was able to connect to LocalDB from IIS Express. Just like LocalDB, IIS Express is a user process. It is started by Visual Studio and runs as the same Windows account as the Visual Studio process. Two different processes running as the same Windows account (Visual Studio and IIS Express, both running as our Windows account) connecting to (localdb)\v11.0 are connecting to the same LocalDB process, also started as the same Windows account.

Possible Solutions

Understanding the nature of the problem brings multiple approaches to solving it. As different approaches have different tradeoffs, instead of prescribing one solution, below I presented three approaches that seem most viable to me. My hope is to hear from you about the one that worked best for you! Here is the list:

• Approach 1: Run IIS as our Windows user
• Approach 2: Use LocalDB Shared Instance
• Approach 3: Use full SQL Server Express

Let's take a closer look at each of them.

Approach 1: Run IIS as our Windows user

If different user accounts are the problem, why not try to run our Web Application under our Windows account? Web Application would connect to the same LocalDB as Visual Studio and everything should just work.

Making the configuration change is relatively easy, just start IIS Manager and find the right Application Pool:

Open Advanced Settings screen (available in the context menu):

Click the little button in the Identity property to bring up the Application Pool Identity screen:

Starting the Web Application again will confirm that the problem is solved:

What are the drawbacks of this approach? Of course running Web Application under our account brings certain security risks. If someone hijacks our Web Application they will be able to access all system resources our account can. Running the Web Application as ApplicationPoolIdentity provides additional protection since ApplicationPoolIdentity accounts have very limited access to local system resources. Therefore I cannot recommend this approach in general, but when used with care it is a viable option in some cases.

Approach 2: Use LocalDB Shared Instance

We could also use an instance sharing feature of LocalDB. It allows us to share a LocalDB instance with other users on the same machine. The shared instance will be accessible under a public name.

The easiest way of sharing an instance is to use SqlLocalDB.exe utility. Just start an administrative command line prompt, and type the following command:

sqllocaldb share v11.0 IIS_DB

It will share the private LocalDB instance v11.0 under the public name IIS_DB. All users on the machine will be able to connect to this instance, using (localdb)\.\IIS_DB as a server address. Note the \. before the instance name, indicating this is a shared instance name. We should replace the connection string in our Web Application with an updated one:

Data Source=(localdb)\.\IIS_DB;Initial Catalog=OldFashionedDB;Integrated Security=True

Before the shared instance can be used by the Web Application we need to start it and create logins for the ApplicationPoolIdentity. Starting the instance is easy, simply connecting to it from SQL Server Object Explorer will start it and keep it alive. Once we are in the SQL Server Object Explorer we can also create the login for ApplicationPoolIdentity. We could use the following query:

create login [IIS APPPOOL\ASP.NET v4.0] from windows;
exec sp_addsrvrolemember N'IIS APPPOOL\ASP.NET v4.0', sysadmin

This script gives full administrative access to our LocalDB instance to the ApplicationPoolIdentity account. Whenever possible, I would recommend using more limited, database-level or even table-level permissions.

Now we can run our Web Application again. This time it should work just fine:

What are the drawbacks of this approach? The main one is that, before Web Application can connect to the shared instance, we need to make sure the instance is started. For that to happen the Windows account that owns the instance must connect to it and the connection must be kept open, or the LocalDB instance will shut down.

Approach 3: Use full SQL Server Express

Since full IIS runs as a service, maybe using traditional, service-based SQL Server Express is the right approach? We could just install SQL Server 2012 Express RC0 and create the OldFashionedDB database in it. We can even use our brand new SQL Server Data Tools to do it, as it works with any SQL Server version and edition. Our connection string would have to change to:

Data Source=.\SQLEXPRESS;Initial Catalog=OldFashionedDB;Integrated Security=True

Of course, just as in the previous case, we would need to make sure the ApplicationPoolIdentity account has access to our SQL Server Express instance. We can use the same script as previously:

create login [IIS APPPOOL\ASP.NET v4.0] from windows;
exec sp_addsrvrolemember N'IIS APPPOOL\ASP.NET v4.0', sysadmin

After that, running our Web Application brings the happy picture again:

What are the drawbacks of this approach? Obviously we lose the benefits of using LocalDB. Installing SQL Server Express may take more time than LocalDB, and there may be some machine cleanup necessary for it to succeed. SQL Server Express Setup can be blocked by problems like corrupt WMI database, polluted registry or components left by SQL Server or Visual Studio CTPs and Betas. And SQL Server Express will continue running in the background even when not needed, as services do.

Other options

There are other approaches of using LocalDB under full IIS that are not covered here. We could embrace the Web Application's private LocalDB instance and communicate with it through the Web Application by executing T-SQL scripts from ASP.NET code. We could also use AttachDbFileName option of ADO.NET connection strings and use a database file (.mdf) that would be attached to both our LocalDB during development and Web Application's LocalDB for debugging. I tried both I found them too cumbersome to discuss further.

Try It Now!

We are eager to hear your feedback on LocalDB. Please share your thoughts with us. Did any of the approaches presented in this post work for you? Did you figure out a better one? Let us know!

You may also want to see other posts and materials about LocalDB:

• Introducing LocalDB and LocalDB Q&A
• Upgrading .NET Framework 4 to support LocalDB connections and using SQL Server Management Studio to work with LocalDB
• Using LocalDB in Visual Studio 2010
• Using LocalDB in Full IIS, Part 1: User Profile
• Using LocalDB in Full IIS, Part 2: Instance Ownership
• LocalDB RC0 and the New LocalDB Installer
• Where are LocalDB database files located?
• SQL Server 2012 Express LocalDB documentation [preview]

- Krzysztof Kozielczyk

Share Your Feedback

Please share your feedback with us! Just start a thread on SQL Express Forum, hit the "Email Author" button on this post, or file a Connect item!

LocalDB and Full IIS

In this recent post I described how to use SQL Server Express LocalDB with Visual Studio 2010. The approach I proposed works for all kind of projects, including Web Applications. However, when it comes to Web Application, there is a catch. An application hosted in Cassini or IIS Express will work as expected, but as soon as we try running it in full IIS (the regular IIS that comes with Windows and runs as Windows service) we are facing the following error:

What Went Wrong?

There are two properties of LocalDB that cause problems when running under full IIS:

• LocalDB needs user profile to be loaded
• LocalDB instance is owned by a single user and private (by default)

We will focus the rest of this post on the user profile, leaving the issue of LocalDB instance ownership for the next post.

Loading User Profile

Let's take another look at the error:

System.Data.SqlClient.SqlException: 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: 0 - [x89C50120])

The error message is not very helpful but LocalDB stores additional information in Windows Event Log. Looking in the Application section under Windows Logs we find the following message:

Windows API call SHGetKnownFolderPath returned error code: 5. Windows system error message is: Access is denied.
Reported at line: 400.

Followed by this one:

Cannot get a local application data path. Most probably a user profile is not loaded. If LocalDB is executed under IIS, make sure that profile loading is enabled for the current user.

Most likely there will be several copies of these two errors, as ADO.NET connection logic attempts to connect multiple times at different intervals:

The second message is clear, the problem we're facing is that the user profile needs to be loaded. That shouldn't be hard since each IIS Application Pool has an option called Load User Profile that can be found in Advanced Settings section. Unfortunately things got slightly more complicated in Service Pack 1 for Windows 7. As described in KB 2547655 enabling loadUserProfile is not enough to fully load user profile, we also need to enable setProfileEnvironment. This requires editing applicationHost.config file which is usually located in C:\Windows\System32\inetsrv\config. Following the instructions from KB 2547655 we should enable both flags for Application Pool ASP.NET v4.0, like this:

<add name="ASP.NET v4.0" autoStart="true" managedRuntimeVersion="v4.0" managedPipelineMode="Integrated">
<processModel identityType="ApplicationPoolIdentity" loadUserProfile="true" setProfileEnvironment="true" />
</add>

Having completed that we restart the Application Pool to make sure the new settings are applied and run our Web Application again. If everything went as expected we should be ... faced by a new error:

There's no reason to panic, as this error is fully expected. After all we haven't dealt with the second problem with running LocalDB under full IIS. We still need to address the fact that by default LocalDB instances are private, which means that IIS, running as ApplicationPoolIdentity, will not have access to our LocalDB instance, running as our Windows account. We will explore different ways to address this problem in the second post from this mini-series on using LocalDB under full IIS.

- Krzysztof Kozielczyk

Share Your Feedback

Please share your feedback with us! Just start a thread on SQL Express Forum, hit the "Email Author" button on this post, or file a Connect item!

Installation

You can download LocalDB from this page. Just pick your CPU architecture (32-bit or 64-bit) and select LocalDB from the drop-down list. Just double-click the SqlLocalDB.msi file is downloaded that will be downloaded. We kept LocalDB simple so there is not a single configuration option in the entire installer. All you need to do is to accept the EULA and click Next a couple times. The installation of LocalDB requires administrative privileges, so if your machine has UAC enabled you will also need to agree to elevate the installation process.

Silent and Embedded Installation

As any decent installer, LocalDB supports silent installation. Here is an example a command that installs LocalDB silently:

msiexec /i SqlLocalDB.msi /qn IACCEPTSQLLOCALDBLICENSETERMS=YES As you can see these are all standard Windows Installer options, except for the IACCEPTSQLLOCALDBLICENSETERMS variable. Setting it to YES is telling us that the user read and accepted LocalDB EULA. As expected the installer will not continue unless this variable is set to YES. If you are considering distributing LocalDB with your application, be sure to put 32-bit and 64-bit versions into separate folders. LocalDB doesn't support installing 32-bit version on 64-bit Windows, so you will need to distribute both versions of LocalDB with your application and they both have the same file name (SqlLocalDB.msi). Renaming LocalDB packages is not an option, as Windows Installer requires that MSI file names don't change (see Rule 14 in this post for the explanation).

Multiple Versions of LocalDB and Upgrades

To keep the LocalDB installation simple we decided that major versions of LocalDB will be installed side-by-side. This way an application using LocalDB version 11 will never be broken by some other application upgrading LocalDB to version 12. Both applications will be able to install the versions of LocalDB they need without interfering with each other. Service Packs for LocalDB will also work in the simplest possible way. In each Service Pack we will release new MSI packages containing all the LocalDB binaries. The updated MSI package can be used to either apply the Service Pack to an existing LocalDB installation or to install a fresh LocalDB installation. In both cases the command line for the silent installation will be the same.

Try It Now!

As you can tell we are fairly satisfied with the final shape of LocalDB, at least for SQL Server 2012. But the final call belongs to you! Please give it a try and share your feedback with us. You may also want to see other posts and materials about LocalDB:

• Introducing LocalDB and LocalDB Q&A
• Upgrading .NET Framework 4 to support LocalDB connections and using SQL Server Management Studio to work with LocalDB
• Using LocalDB in Visual Studio 2010
• LocalDB RC0 and the New LocalDB Installer
• Where are LocalDB database files located?
• SQL Server 2012 Express LocalDB documentation [preview]

- Krzysztof Kozielczyk

Share Your Feedback

Please share your feedback with us! Just start a thread on SQL Express Forum, hit the "Email Author" button on this post or file a Connect item!

In my recent post I was using .NET Framework 4.0.2 to enable SQL Server Management Studio to connect to LocalDB. It all worked rather well and I declared success and moved on to another topic. I conveniently kept silent about connecting to LocalDB from Visual Studio 2010. For a good reason -- currently Visual Studio 2010 doesn't really work with LocalDB. There are two reasons for that:

• The SQL Server database experiences in Visual Studio 2010 are built on top of User Instances of SQL Server Express. Using LocalDB to power them is more complex than just changing a connection string to (localdb)\v11.0. It would require releasing some kind of a wide patch for Visual Studio 2010.
• LocalDB was introduced in SQL Server 2012 CTP3. Visual Studio 2010 only supports SQL Server 2008 R2 and earlier.

In effect, even though adding the connection to LocalDB to Data Connections node of Server Explorer will succeed, trying to open any database designer from this connection will result in this sad message:

Is There At Least a Hack?

At this point the situation might seem pretty grim. Without Visual Studio 2010 support for LocalDB, developers that want to try it would need to wait for the next Visual Studio release. How can we get your feedback on LocalDB if there's no way to try it for months?

Fortunately, many Visual Studio 2010 features actually work with LocalDB and we should be able to use SQL Server Management Studio for the missing parts. We could also take the opportunity to try the new SQL Server Data Tools -- I will post about working with LocalDB from SSDT soon, as it integrates into Visual Studio, providing developers with a nice alternative for usig SSMS.

I already covered how to connect to LocalDB from SSMS and create databases, tables, input data and so on. Let's look at how we can use them from the Visual Studio 2010.

As I mentioned earlier creating a connection to LocalDB in the Data Connections node of Server Explorer will just work. Let's give it a try! One way to do it is to right-click the Data Connections node and select Add Connection...

We should use the standard LocalDB connection string: (localdb)\v11.0

Clicking OK and done, the connection is created!

Don't worry about the strange format of the connection -- we will soon see that the connection indeed points to our usual LocalDB instance.

The next step is to use the connection. Let's create a DataGridView control by dragging it from the Toolbox panel.

As we can see the DataGridView is not connected to any data source. Let's bind it to our LocalDB connection. Click Add Project Data Source... link on the Tasks quickview of the DataGridView control to bring up the data connection wizard and select Database and Dataset on the next two screens.

When asked about the connection, pick the LocalDB connection from the list. Once it's selected we can confirm that it points to LocalDB by looking at the Connection string property.

The last step is selecting a table to be presented in the DataGridView. After finishing the wizard the DataGridView should have the same columns as the underlying table, like this:

We're done. Hold your breath and hit F5 to run the application. With any luck it should start and the DataGridView should present the data from the table, like on this screenshot:

That was easy, wasn't it? :-)

Try It Now!

This walkthrough covers just one scenario, but the same approach should work in other scenarios as well. Just use SSMS or SSDT to create your database and Visual Studio to connect to it. Please try out your favorite scenario and share your feedback!

You may also want to see other posts and materials about LocalDB:

• Introducing LocalDB and LocalDB Q&A
• Upgrading .NET Framework 4 to support LocalDB connections and using SQL Server Management Studio to work with LocalDB
• Using LocalDB in Visual Studio 2010
• LocalDB RC0 and the New LocalDB Installer
• Where are LocalDB database files located?
• SQL Server 2012 Express LocalDB documentation [preview]

- Krzysztof Kozielczyk

Share Your Feedback

Please share your feedback with us! Just start a thread on SQL Express Forum, hit the "Email Author" button on this post or file a Connect item!

The regular SQL Server assumes that it is actively managed by a DBA. The DBA carefully configures SQL Server during the installation and afterwards. The DBA decides where SQL Server binaries are installed. The DBA also decides where the system database files are located. The location of the system databases also becomes the default location for all user databases.

LocalDB is different. It's built to be used by developers, not DBAs. And we have heard developers saying loud and clear that they just want to focus on their databases and database code. Therefore our primary design goal was to eliminate all the server configuration and management that is getting in their way. As a result LocalDB stores all the system databases deep inside the "hidden" AppData folder in the user profile. For example, after playing with the Automatic Instance in the previous post, I find this folder in my user profile:

This folder constitutes my Automatic LocalDB Instance. Any good DBA will explain in great and painful details what these files are, but if you are a developer this is the first and the last time you will look at them. Which is great, but left us with an interesting question. If the location of system databases is hidden from the developer, what should the default location for the databases created by the developer be? Creating user databases in a hidden folder didn't seem like the right design. We considered My Documents too, but that could give the impression that SQL Server databases are portable documents. Plus half of our team was using some sort of document synchronization solution, like Live Mesh. Those would quickly destroy the database files and we thought they will only get more popular over time, thus more likely to wreck havoc in the future.

In the end we decided to create the database files in the root of the user profile. On most machines it is located in C:\Users\user-name folder

In the spirit of a scientific approach, let's try it out. Open SSMS and connect to your Automatic Instance:

Then create database foo without specifying the location for its files:

create database foo

Open Windows Explorer and navigate to your profile (typing %USERPROFILE% in the address bar is a nice shortcut). If the database was created successfully there will be new files in this folder, foo.mdf and foo_log.ldf that represent your database. QED.

Given that user profile folder is likely not the best location to store database files, we advise developers creating databases to always specify the location for the database files, like in this T-SQL example:

create database foo on (name='foo', filename='c:\DBs\foo.mdf')

- Krzysztof Kozielczyk

Send us Your Feedback

Please share your feedback with us! Just start a thread on SQL Express Forum, hit the "Email Author" button on this post or file a Connect item!

Updated 2012-01-03: Clarified that only SSMS from SQL Server 2012 (or newer) will work with the .NET 4 Update 4.0.2, since earlier SSMS versions are using .NET 3.5.

.NET Framework 4 Update 4.0.2

.NET team has just released Update 4.0.2 for .NET Framework 4. This update enables connecting to SQL Server Express LocalDB via System.Data.SqlClient provider.

.NET Framework 4 Update 4.0.2 can be downloaded from https://support.microsoft.com/kb/2544514

Does this work?

Well, let's give it a try!

We start by installing SQL Server 2012 Management Studio RC0 (SSMS) and LocalDB together with .NET 4. The version of SSMS is important as earlier versions are using .NET 3.5 and currently only .NET 4 can be updated to understand LocalDB connection strings. Next we update .NET 4 to 4.0.2 (hey, no reboot in my case!). Then fire up SSMS. When prompted for the server address we specify "(localdb)\v11.0", like this:

Clicking Connect and … (drum roll please!) …

Success!

Does it really work?

OK, so we confirmed SSMS connects to LocalDB. Which is great, but how about doing something more useful for a developer? The next logical step would be to create a database. We know the drill -- right-click the Databases node in Object Explorer and select New Database. So far, so good. After typing in the name of the new database (in my case LocalDBTest) we are ready to hit OK...

Clicking OK and ... we hit an error!

This is obviously a bug, but there are at least two reasons we shouldn't panic. First, the bug has an easy workaround that we're going to use very, very soon. Second, it points to an important characteristic of the way LocalDB handles database files. I will explain it in more detail in the next post, but for now let's get back to LocalDB and creating our database.

To work around this problem we need to explicitly specify the folder for the database files. For the lack of a better location let's just put them into My Documents, like this:

This time clicking OK creates the database without any problems.

We are now ready for some serious database development, but this too will have to wait for another post.

- Krzysztof Kozielczyk

Send us Your Feedback

Please share your feedback with us! Feel free to start a thread on SQL Express Forum, hit the "Email Author" button on this post or file a Connect item!

Introduction

Background

High-Level Overview

1. LocalDB uses the same sqlservr.exe as the regular SQL Express and other editions of SQL Server. The application is using the same client-side providers (ADO.NET, ODBC, PDO and others) to connect to it and operates on data using the same T-SQL language as provided by SQL Express.
2. LocalDB is installed once on a machine (per major SQL Server version). Multiple applications can start multiple LocalDB processes, but they are all started from the same sqlservr.exe executable file from the same disk location.
3. LocalDB doesn't create any database services; LocalDB processes are started and stopped automatically when needed. The application is just connecting to "Data Source=(localdb)\v11.0" and LocalDB process is started as a child process of the application. A few minutes after the last connection to this process is closed the process shuts down.
4. LocalDB connections support AttachDbFileName property, which allows developers to specify a database file location. LocalDB will attach the specified database file and the connection will be made to it.

LocalDB Instances

Database as a File

New Installer

LocalDB and User Instances of SQL Express

LocalDB and SQL Express

LocalDB and SQL Server Compact?

1. Execution mode: SQL Server Compact is an in-proc DLL, while LocalDB runs as a separate process.
2. Disk usage: all SQL Server Compact binaries amount to some 4MBs, while LocalDB installation takes 140MBs.
3. Features: SQL Server Compact offers core RDBMS functionality like querying, while LocalDB provides a much richer set of features, including Stored Procedures, Geometry and Geography data types, etc.

Send us Your Feedback

Q&A

A: LocalDB is supported by System.Data.SqlClient in .NET Framework 4 Update 4.0.2, as announced in this post.

I posted more information about this release to https://blogs.msdn.com/petersad/archive/2010/04/26/installing-sql-server-2008-r2-express.aspx.