LocalDB introduction and use in VS2012 and above

Before accidentally put their own computer on the SQL Server changed, uninstall did not immediately reload, so study a bit localdb, feel good, especially when the individual to do development or testing, so record and share to everyone. OK, let's get started: what is LocalDB?

With the release of SQL Server 2012, LocalDB jumps into our line of sight, which can be seen as a lightweight version of SQL Server Express.

LocalDB is created specifically for developers, it's very easy to install, almost no management, compatible with the T-SQL language, programming interfaces with SQL Server Express indistinguishable.

With LocalDB, developers don't need to install and maintain a large instance of SQL Server on their notebooks. In addition, the LOCALDB is also suitable for small application environments where developers can use it for small production environments or embedded environments. LocalDB's core technical features are compatible with other versions of SQL Server, using Sqlservr.exe as a service process, using the same client access interface (such as ADO, ODBC, or PDO) and compatible with the T-SQL programming language. You do not have to install multiple localdb on the same computer, and different applications can execute multiple LOCALDB processes in parallel, but all processes are started from the same executable file (Sqlservr.exe). LocalDB does not create any system services, and the LOCALDB process automatically starts and stops as needed. The application simply connects to "Data source= (LocalDB) \v11.0", and LocalDB is started as a child of the application. As the connection terminates, the LOCALDB process also stops. LocalDB supports the AttachDbFileName property, which allows the developer to specify the database file location. For example:

Data Source = (localdb) \v11.0;  Integrated Security = true;  AttachDbFileName = C:\MyData\Database1.mdf

using LocalDB in Visual Studio

Using LOCALDB requires VS's version at 2012 or above. I demonstrate here that the code First mode of the Entity Framework will be used. The first step: Create a console application:

Step Two: Use NuGet to add a reference to the Entity Framework:

Step Three: Create Entities and DbContext:

Public  class Product
    {public
        int ProductID {get; set;}
        public string Name {get; set;}
        public string Description {get; set;}
        Public decimal price {get; set;}
        public string Category {get; set;}
    }
    Class Efdbcontext:dbcontext
    {public
        dbset<product> products {get; set;}
    }

final step (and most critical): Modify the connection string in the app. config configuration file:

<connectionstrings >
    <add name= "Efdbcontext" providername= "System.Data.SqlClient" connectionstring= " Data source= (LocalDB) \mssqllocaldb;initial catalog=sportsstore;integrated Security=sspi; Attachdbfilename=e:\sportsstore.mdf "/>
  </connectionStrings>

The value of the data source here is an instance of the specified localdb. In this connection string there is also a AttachDbFileName property, which is used to specify the path of the database file (including. mdf and log files), which I place in the e-packing directory, if not specified, the database will be created to the default address (C-drive your users). Other attributes I believe we are not strangers. test Result: Add the following code to the main function of Program.cs:

using (Var context=new efdbcontext ())
            {
                context. Set<product> (). ADD (new Product {price = 1, Name = "P1", Category = "a", Description = "None"});
                Context. SaveChanges ();
              List<product> products=  context. Set<product> (). ToList ();
                foreach (Product  p in products)
                {
                    Console.WriteLine (P.productid + "" +p.name + "" +p.price);
                }
            }
            Console.readkey ();

To run the debug:

The following files appear under the root directory of the local disk E:

The SQL Server object Browse window in VS also sees:

Summary

LocalDB is a lot lighter than SQL Server, although it does not offer many features but is sufficient for many developers and testers. It is also extremely convenient to use, only need to modify the connection string, our program how to write or how to write it.

Reference Link: http://www.csdn.net/article/2012-03-29/313675