We are moving database from one server to another. There are many connection strings of applications that needs to changed due to this. Is there any generic way where we can keep the connection string so that if we move the database again then this issue doesn't arise??
There are so many ways to resolve this problem.
Ultimately what it sounds like you want to do is centralize your database connection strings in such a way that a database migration is (mostly) transparent to your application. I can think of a few options here:
Use a "control database" that houses your connection strings and configurations. If you migrate to a new database server, you only have to update a single connection string in your application, and perform data updates for everything else. This is what I personally use.
Use a central XML configuration file that is parsed on application startup.
Use SQL Server Aliases and/or add additional IPs to the machine that you can migrate between servers. This way when you move to a new database server you can still bring along the existing aliases/IPs to that server (unless they need to run in parallel of course) and theoretically not need to update anything in your code, provided that you've referenced the appropriate aliases. See here for more info: https://dba.stackexchange.com/questions/56642/how-to-create-a-server-alias-in-sql-server-2012
Over here we ultimately went with option 1 because that gave us more flexibility and reliability than an XML configuration file (#2) and required less configuration and special cases to be documented with our DBAs, since we have no ownership of any database servers outside of our DEV environment.
Have the connection string in an xml file and read the xml file and get the connection string from it. You only need to change the connection string in the xml file and not in the published code. By the way you can have multiple connection strings for Debug and Release modes and make your application choose it.
You could store them in a database. ^_^
Jokes aside, I do not have experience with this myself, but using an Alias sound like it might suit you best:
http://blog.idera.com/sharepoint/performance-webcasts/plan-your-sharepoint-farm-right-with-a-sql-server-alias/
First, you can store your connection strings in external file (custom storage or .config file) - so you will be able to change them without recompiling the code.
Second, you can use domain name instead of IP address
And third, you can store your connection strings in parts and build them in runtime by ConnectionStringBuilder - so you can change only server part.
Related
I make a windows form application with its database and I want to publish it . the app is running in my system so good but when I run it in another PC its shows errors about cannot connect to its database.
also I put database mdf and ldf file in program folder but my app doesn't work.
and this is my connection string :
string connectionSt = "Data Source=DESKTOP-NLKJ55F;Initial Catalog=IndustryContracts;Integrated Security=True";
This is a common mistake for people learning how to develop apps with databases.
Basically: You have the wrong approach. A database is not really meant to be created at every computer where a program is installed. Rather, the ideal use case for a database is one which is created in a server, and any app that requires to use it will simply connect to it, by some protocol like TCP. This helps with encapsulation and also makes your application more compact.
So normally when the program needs to read and write data to be saved somewhere, people usually go with methods such as writing into a CSV file, or a tab delimited file, and then reading from those files.
There is also another option, which is to use a serverless DB such as SQLite, however, this would mean you need to learn how to implement said database.
Lastly, as a really discouraged way to do it, and a bit of a "brute force" approach, you can copy the database creation script, install a DBMS in your target computer, run the script to create the DB, then change the connection string of the DB in your program to match the newly created instance, then install the program. See how extremely clunky that was?
Remember: Most databases run in a server, even if that server is your PC, hence why they're referred to as instances. Naturally a server shouldn't be replicated every time a program is installed.
Is that possible to create a database that's already included in the project and without opening the database application?
Because, I have to publish the system that I made.
I think that you might be interested by in-memory databases, It is treated here.
You could also have a remote database, giving the capacity to anyone with your application and appropriate credentials to connect to it.
If you are looking for a other alternative, you could also export the Scheme and/or Data of a database to a portable .sql file.
Normally, in a .NET application, you store your database connection strings in the app.config.
For a single .exe, there's a single .exe.config. And we're using Entity Framework, which defaults to using a .config setting that matches the DbContext name. Which all works fine, so long as you follow the common pattern of having a single instance of an application talking to a single database.
But our problem requires we have multiple instances of our application, each with its own distinct database connection.
Possible solutions:
Create multiple copies of the .exe, each with its own copy of the .config, and put a different connection string in each. Advantage? No coding changes. Disadvantage? Maintaining all the different copies, making sure they all get updated, etc.
Keep one copy of the .exe, with one copy of the .config, and put multiple connection strings in the .config. Then pass a command-line argument to the program that selects which connection string to use. Advantage? Only one .exe to manage. Disadvantage? Coding change, likelihood that someone's going to mess up the command-line arguments.
Some other brilliant idea, that someone here on Stack Overflow is going to point out to me.
Any ideas?
I'm sure people have dealt with this issue, before. Is there a common way of handling the issue?
You can also think of creating copies of config file and load the appropriate one based on command line parameter using following code:
AppDomain.CurrentDomain.SetData ("APP_CONFIG_FILE", "path to config file")
See this for detail: Relocating app.config file to a custom path
You could try something like this within some C# applications to change the connection string per application.
var config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
var connectionStringSection = (ConnectionStringsSection)config.GetSection("connectionStrings");
connectionStringSection.ConnectionStrings["database"].ConnectionString = string.Format("Data Source={0}", userCon);
config.Save();
ConfigurationManager.RefreshSection("connectionStrings");
I've read a few links but most are in relation to when deploying or i've missed a trick in the middle so dont fully understand hence asking the below question......
I have a live, test and local environment (all have their own individual connection strings). I create a solution with 2 projects (for example) 1 is a ASP .Net website and other is a Class Library. Within the class library i add a Linq to SQL and add a connection to it. The connection string is stored in an app.config file.
What i would like to do is be able to switch between the environments so the connection string is updated to reflect the environment i am using without having to manually type in the connection string. I've seen this done but not sure how to do it myself? Im using VS2010. Could anyone advise or point me in the right direction?
Thanks
You could potentially use #if DEBUG and have two connections strings in your app.config - one called Test one called Live - I would suspect that debugging would indicate that you are in the test environment and on release you would be live.
Please refer to this link http://msdn.microsoft.com/en-us/library/4y6tbswk.aspx
Another option is to simply have an input at some point to indicate which environment the application is running on - you could do this with a checkbox or radio button or even through appSettings in app.config by specifying ConnectionMode and setting it to 1 or 2 if the setting reads 1, then use the test connection string, if it reads 2 Live connection string.
If I could make the connection string a "User" setting for them to edit, that would do nicely for now. At the moment the string contains a reference to my machine, where my test DB sits. I want to build an alpha for somebody else to try, but they'll need to point it to their own DB instance.
More generally, what is the correct approach to keep DataSets in the Visual Studio designer whilst having a connection string capable of being pointed to the configured server by the user? - at the moment they seem dependant on the Connection String in my Settings.
Use app.config with System.Configuration, they can then set the correct connection string in the config.
See this question for how:
Get connection string from App.config
Because, presumably, the ConnectionString back to your database contains highly sensitive information, such as server names, database names, even user ID's and passwords; as such, that information is inherently designed to be disguised or kept secret from the user community. Malevolent users of your application would very much enjoy the opportunity to leverage a user-controlled connection string.
It would seem that if you need to control data in this way, you should consider some kind of profiling mechanism that performs the specific data host selection in the background, not in an entirely user-controlled manner.
Edit
One possible alternative I would suggest is to determine the "alternative" servers in advance, and add the corresponding connection strings to the app's configuration file. In the application itself, provide some sort of user-friendly identifier that ties to the dataset the user wants to use, then tie that identifier behind the scenes to the proper connection string, thus keeping the particulars of the connection string private.