CODEWITHSUNDEEP
sql-server-express
Subbu
Subbu

Reputation: 829

SQL Server Express exception in desktop .NET application

I have developed a .NET desktop application which uses SQL Server 2005 SP3 Express.

After installing the SQL Server Express runtime and application on a Windows 7 64 bit machine, I get the following error after launching the application:

System.Data.SqlClient.SqlException: Failed to generate a user instance of SQL Server due to a failure in starting the process for the user instance. The connection will be closed.

The connection string I have used in the <application>.exe.config file is : 

<add name="cs" connectionString="Data Source=.\SQLEXPRESS;
    AttachDbFilename=|DataDirectory|\AppData\MWAIWFMLE1.mdf;
    Integrated Security=True;
    User Instance=True"
    providerName="System.Data.SqlClient" />

The MWAIWFMLE1.mdf file is located in a folder called AppData in the application install directory under program files - hence the AppData in the AttachDbFileName path.

Am I missing something here?

Upvotes: 0

Views: 200

Answers (1)

marc_s
marc_s

Reputation: 754598

Read this very good overview of what user instances really are.

In a nutshell:

  • SQL Server allows you to have multiple instances of itself on a single computer - the default instance can be accessed using just the machine name (or IP address) of the host machine - all other instances need to be specified by an instance name (like the SQLExpress on your machine)

  • for development purposes, you can also create a user instance - each user gets their own separate instance of SQL Server (works in the Express edition only) and a database is attached by its file name (path\Sales_DB.mdf) to that user instance. This instance is started up on demand, then runs and is shut down when no longer needed

While this works great for development, it's not really intended for later on - certainly not for production use.

In a production environment, you want to attach your database files to the actual SQL Server instance they should run on - typically using SQL Server Management Studio. When you do this, you no longer refer to that database via its file name, but instead you use the database name that was given to the database when being attached to the server. In this case, SQL Server will handle all details of operations - and that SQL Server instance is up and running all the time (doesn't need to be started "on demand" all the time), and you can use things like permissions and logins to control access to the database.

Your connection string would then look something like this:

<connectionStrings>
    <add name="Sales_DBEntities" 
         connectionString="server=.\SQLEXPRESS;Database=YourDatabaseNameHere;Integrated Security=SSPI;" />
</connectionStrings>

When you have attached a database to a production (or testing) SQL Server instance, you do not need to know what the files are that make up the database, and you don't need to specify those files - SQL Server will take care of that. You just refer to the database via its database name.

Upvotes: 2

Related Questions