I have produced a small program that uses a database created in MS Access. I have created about 5 queries for the database to test it and everything is working fine. I want to learn something new, so I decided to improve my program by migrating DB to SQL Server, but I don't really know where to start from. I have installed MS SQL Server 2012 and looking for some tutorials/pointers for beginners. My initial goals are:
Convert MS Access database to SQL Server
I believe that the up-size wizard included in MS Access can be sufficient for the job. Am I right?
Connect my C# program to DB saved on SQL Server
I think that I should edit my connection string and replace OleDb with something else... What should it be?
I am not sure if the tool exists also for Sql Server 2012 but in 2008 R2 you have a menu entry in the Program Group for Sql Server called Data Import Export (32bit) (Translated from my localization, hope to be near at the exact thing) that could be used to port an MS Access Database to a SQL Server. Of course you need install Sql Server Management Studio to manage the fine details of your new database.
For the code part (connection string) you could continue to use OleDb changing only the connection string (see here at www.connectionstrings.com), but your best option is to change everything and use the classes in the namespace System.Data.SqlClient like SqlConnection instead of OleDbConnection, SqlCommand instead of OleDbCommand and so on....
Related
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.
I'm very very new to SQL Server, and I have written a program in Visual Studio using C# that uses a table from a database that I have created using SQL Server Management Studio. But if I try to run my program on another device, it either asks for a version of SQL Server to be installed or it fails to connect to the server because I used the local option to create the said database and therefore, the other device doesn't have the permission to connect to it.
I have read somewhere that I should use in-memory databases so that other devices can run this program without connecting to me or needing SQL Server to be installed? Can I store the database somewhere in the project and tell my program to seek it and load it?
TLDR; how to use the features of SQL Server like database and tables while offline and without the need to connect to any server or even the need to install SQL Server itself if possible.
And sorry for my bad English!
Ok so i know I'm fairly new to C# and MVC but I'm trying to use the code first approach of adding items to a database.
Now I have successfully created new entries to the database but when I go to SQL Server i cannot find the database or tables.
So my question is where is this data being stored as I can't see it in SQL Server like my other databases that I manually created?
My ConnectionString is:
Data Source=(LocalDb)\v11.0;AttachDbFilename=|DataDirectory|\aspnet-Testing-20140809020449.mdf;Initial Catalog=aspnet-Testing-20140809020449;Integrated Security=True
LocalDb is the new server-less version of SQL Server that has similar features as SQL Express. I would describe it as a just-in-time version of SQL Server that is only running when needed.
In order to connect to it usng SQL Server Management Studio, you need to connect using the following connection string (assming SQL Server Version 11/2014 may change to 12 or higher in future versions):
Then you'll have access to the database.
[project_dir]\App_Data\aspnet-Testing-20140809020449.mdf
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.