I am facing a very weird situation where by my company wants me to use SQL Server Express. But the issue is I need to use the same SQL Server Express database for connection by different projects.
How do I do that?
I am using Entity Framework and C#.
You'll need to copy your .mdf from your App_Data folder into SQL Server Express's data folder, attach the database to your Express instance, and then change your connection string to reference the instance instead of the location of the .mdf.
This answer to a similar question gives detailed, step-by-step instructions for this process.
It seems you are trying to attach local database file with AttachDbFilename= option in the connection string. But you can't simultaneously attach the same .mdf on a local drive with several concurrent applications (like you can do with MS Access).
Rather just install SQL Server Express on a central computer and open it up for remote TCIP/IP access, attach your database to it and change the connection string to an IP / instance one.
Related
How can I use my LocalDB on other computers?
SqlConnection connection = new SqlConnection(#"Data Source=(LocalDB)\v.11.0;AttachDbFilename=[DataDirectory]\Database1.mdf;Integrated Security=True");
I tried this but it doesn't work because I get this error:
Local Database Runtime error occurred. Cannot create an automatic instance
Does someone know how to fix this, or what I can do instead?
I don't want to use SQLServer because I am making a program for an offline computer.
The fact that your app is for an offline computer is irrelevant. If you're attaching an MDF file on demand then that will only work with a SQL Server instance installed on the local machine anyway.
As suggested elsewhere, LocalDB is intended for development use only. Your users should be installing SQL Server Express and you can specify that in the connection string. If you're going to use a SQL Server data file, i.e. an MDF file, then you need a SQL Server instance to attach it to. If you don't want to have to have a SQL Server instance installed then don't use a SQL Server data file in the first place.
LocalDb is sql server and is only intended for development purposes. It isn't something you would use for distributing an application. SQL Express is an option for you, but may be overkill for what you need. You might look into SQLite as you might find it easier to embed and distribute with your application. Of course, the right answer depends on your actual requirements, etc.
Apparently, using AttachDbFilename and user instance in your connection string is a bad way to connect to a DB. I'm using SQL server express on my local machine and it all seems to work fine. But what's the proper way to connect to SQL server then?
Thanks for your explanation.
Using User Instance means that SQL Server is creating a special copy of that database file for use by your program. If you have two different programs using that same connection string, they get two entirely different copies of the database. This leads to a lot of confusion, as people will test updating data with their program, then connect to a different copy of their database in Management Studio, and complain that their update isn't working. This sends them through a flawed series of wild goose chase steps trying to troubleshoot the wrong problem.
This article goes into more depth about how to use this feature, but heed the very first note: the User Instance feature has been deprecated. In SQL Server 2012, the preferred alternatives are (in this order, IMHO):
Create or attach your database to a real instance of SQL Server. Your connection string will then just need to specify the instance name, the database name, and credentials. There will be no mixup as Management Studio, Visual Studio and your program(s) will all be connecting to a single copy of the database.
Use a container for local development. Here's a great starter video by Anna Hoffman and Anthony Nocentino, and I have some other resources here, here, and here. If you're on an M1 Mac, you won't be able to use a full-blown SQL Server instance, but you can use Azure SQL Edge if you can get by with most SQL Server functionality (the omissions are enumerated here).
Use SqlLocalDb for local development. I believe I pointed you to this article yesterday: "Getting Started with SQL Server 2012 Express LocalDB."
Use SQL Server Compact. I like this option the least because the functionality and syntax is not the same - so it's not necessarily going to provide you with all the functionality you're ultimately going to want to deploy. Compact Edition is also deprecated, so there's that.
Of course if you are using a version < SQL Server 2012, SqlLocalDb is not an option - so you should be creating a real database and using that consistently. I only mention the Compact option for completeness - I think that can be almost as bad an idea as using AttachDbFileName.
EDIT: I've blogged about this here:
Bad Habits : Using AttachDBFileName
In case someone had the problem.
When attaching the database with a connection string containing AttachDBFile
with SQLEXPRESS, I noticed this connection was exclusive to the ASP.NET application that was using the database. The connection did block the access to all other processes on the file level when made with System.Data.SqlClient as provider.
In order to assure the connection to be shareable with other processes
instead use DataBase to specify the database name in your connection string
Example or connection string :
Data Source=.\SQLEXPRESS;DataBase=PlaCliGen;User ID=XXX;password=ZZZ; Connect Timeout=30
,where PlaCliGen is the name (or logical name) by which SQLEXPRESS server knows the database.
By connecting to the data base with AttachDBFile giving the path to the .mdf file
(namely : replacing DataBase = PlacliGen by AttachDBFile = c:\vs\placligen\app_data\placligen.mdf) the File was connected exclusively and no other process could connect to the database.
Apparently, using AttachDbFilename and user instance in your connection string is a bad way to connect to a DB. I'm using SQL server express on my local machine and it all seems to work fine. But what's the proper way to connect to SQL server then?
Thanks for your explanation.
Using User Instance means that SQL Server is creating a special copy of that database file for use by your program. If you have two different programs using that same connection string, they get two entirely different copies of the database. This leads to a lot of confusion, as people will test updating data with their program, then connect to a different copy of their database in Management Studio, and complain that their update isn't working. This sends them through a flawed series of wild goose chase steps trying to troubleshoot the wrong problem.
This article goes into more depth about how to use this feature, but heed the very first note: the User Instance feature has been deprecated. In SQL Server 2012, the preferred alternatives are (in this order, IMHO):
Create or attach your database to a real instance of SQL Server. Your connection string will then just need to specify the instance name, the database name, and credentials. There will be no mixup as Management Studio, Visual Studio and your program(s) will all be connecting to a single copy of the database.
Use a container for local development. Here's a great starter video by Anna Hoffman and Anthony Nocentino, and I have some other resources here, here, and here. If you're on an M1 Mac, you won't be able to use a full-blown SQL Server instance, but you can use Azure SQL Edge if you can get by with most SQL Server functionality (the omissions are enumerated here).
Use SqlLocalDb for local development. I believe I pointed you to this article yesterday: "Getting Started with SQL Server 2012 Express LocalDB."
Use SQL Server Compact. I like this option the least because the functionality and syntax is not the same - so it's not necessarily going to provide you with all the functionality you're ultimately going to want to deploy. Compact Edition is also deprecated, so there's that.
Of course if you are using a version < SQL Server 2012, SqlLocalDb is not an option - so you should be creating a real database and using that consistently. I only mention the Compact option for completeness - I think that can be almost as bad an idea as using AttachDbFileName.
EDIT: I've blogged about this here:
Bad Habits : Using AttachDBFileName
In case someone had the problem.
When attaching the database with a connection string containing AttachDBFile
with SQLEXPRESS, I noticed this connection was exclusive to the ASP.NET application that was using the database. The connection did block the access to all other processes on the file level when made with System.Data.SqlClient as provider.
In order to assure the connection to be shareable with other processes
instead use DataBase to specify the database name in your connection string
Example or connection string :
Data Source=.\SQLEXPRESS;DataBase=PlaCliGen;User ID=XXX;password=ZZZ; Connect Timeout=30
,where PlaCliGen is the name (or logical name) by which SQLEXPRESS server knows the database.
By connecting to the data base with AttachDBFile giving the path to the .mdf file
(namely : replacing DataBase = PlacliGen by AttachDBFile = c:\vs\placligen\app_data\placligen.mdf) the File was connected exclusively and no other process could connect to the database.
here is the problem I am facing now. I have created an application that uses local database (this was created by Add -> New Item -> Local Database. Afterwards I have added tables under this .sdf database.
Then I have connected to this database using Add -> New Item -> ADO.NET Entity Data Model.
Everything works like a charm, unless I was asked to move this database to a place, where multiple people could access this database and work with it.
Therefore, as I have no previous experience with databases, I have treated this .sdf file as any other file (let's say Excel workbook) and I thought that I could simply take already existing database, copy it on server computer (e.g. \Server001\Database\Database1.sdf) and simply change connection string under app.config.
However the problem is that this does not work. As I didn't know how to change connection string, I created new application, where I have tried to connect to this database located on a server computer; however I received the following error:
SQL Server Compact does not support opening database files on a network share.
I already have fully functioning program, but I have no idea how to make it work with multiple users. I have tied to google for solution, but all I could find is how to create local database, not how to make it accessible by placing it in server computer.
Could you guys please help me? If you need more details, please let me know!
P.S. This is WPF application, .NET 4.5, created using Visual Studio 2012 Professional.
Thank you!
The error message pretty much sums up the problem: SQL Server Compact does not support opening database files on a network share.
SQL Server Compact (aka "local database") is to be consumed by a local application; even if it was a web app serving many requests, the application itself is local.
If you want to have multiple remote connections (i.e. centralized DB, distributed app), you should look at using an instance of SQL Server (any SKU would probably work, even SQL Server Express). Those will use MDF files instead of SDF files, so you might want to refer to Convert .sdf database to .mdf database. You'll probably also need to set up a user identity for your connection string, so check out this link on CREATE USER and Difference between a User and a Login in SQL Server to understand how that can be configured.
On my development computer I have MS SQL Server/Visual Studio 2005. My program can correctly connect to my local DB and use it. However my other computer (non-dev) does not have MS SQL Server/Visual Studio 2005 and does not connect to the DB. It spits out the following:
"An error has occurrred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. ..." (Error: 26).
Does this mean I have to install SQL Server 2005 on my non-dev computers? Is there any other way?
My connection string is:
"Data Source=.\SQLEXPRESS;AttachDbFilename=\""
+ Directory.GetCurrentDirectory()
+ "\DB.mdf\";Integrated Security=True;User Instance=True";
Your connection string is telling the Sql Server Native Client ADO.NET Provider to attempt to connect to a Sql Server instance named SQLEXPRESS that will manage the database stored in a file DB.mdf. Since your client computer does not have Sql Server Express installed, it's not going to find a database to connect to.
You will need to:
Install Sql Server on the client computer and deploy your database there.
Switch to Sql Server Compact Edition (SqlCE - embedded database) and re-architect your application to use the portable database file (with SqlCE) instead.
Ditch using a robust database engine and switch entirely to ADO.NET DataSets, saving/loading the contents of the DataSet to an Xml file (via WriteXml() and ReadXml()). If the amount of data you are processing is fairly limited in size, DataSets are a good approach to maintaining integrity (via a strongly typed and well-defined schema) and portability.
If you want to run it on that other pc/server you also need to have SQL Server (need to attach your .mdf to it) or SQL Server Express installed.
Another trick would be to change your connection string so that it points out to another pc/server where your database runs on.
Yes, you do need MS-SQL (Express) available on your target computers. Either a local install or a connection to a server.
It is not that difficult to include SQl Express in a Setup.exe (see PreRequisites).
An alternative is to use SQL-CE or Sqlite or (even) MS-Access. They are 'embedded' database engines so that you only need to distribute DLLs.