We Keep Coding

C# Connection string save into AppData?

So I have a DB (webster.accdb) which will be getting installed on a server (eg. \SERVER\WEBSTER)
However different locations may have differing SERVER names (ADMIN1 etc etc)
When the program originally installs, it checks the con string in app.config which I have put as "DEFAULT" - literally the string.
The program checks the connection string in app config, and if it is DEFAULT, then it runs a little prompt i have made which asks for details from the user regarding the server name and a few other specifics.
They click "connect" and it writes the newly constructed connection string to app.config and the program loads after a series of tests.
Now this works under VS tests and installs on D: drives in temp folders. My issue is that if 'properly' installed to the programfiles section, then we now have the issue of access being denied to alter the file.
So could someone point me in the right direction with regards to the correct process as i know I'm doing it wrong:
Create an XML in Appdata for the user, which has the con strings, and this is generated on first use, and is used for the constrings from then on?
Save the con strings as Settings, and use This code to update settings, then make sure all my con strings in my program no longer point to configuration, but to settings??
Something better because I am clueless and this is totally not how i should be doing this at all!
Code used to update the config:
Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
config.ConnectionStrings.ConnectionStrings["LOTSConnectionString"].ConnectionString = "Data Source=" + txtpcname.Text + ";Initial Catalog=" + cmbdispense.SelectedItem + ";Integrated Security=False;User ID=webbit;Password=ill923r6MG";
config.Save(ConfigurationSaveMode.Modified, true);

Access Denied means the user which is executing the app either does not have permission or because of inbuilt security by Operating System, app is executing under restricted permissions. Try executing app with Administrator by right clicking on it and choosing run as.
You can prevent this by Setting up connection string at the time of installation instead. Prompt a user to enter details during installation.

So pretty much I self confess to not understanding the benefits of the USER section of the config.
I have changed my connection strings to just "STRING" and put in the USER section of Settings.
Now i can refer to my strings as
properties.settings.default["ConString"].tostring
This is then saved to User/APPDATA/Local
For noobs like me reading this, that means the original app.config file in programfiles stays THE SAME, but an excerpt is taken out of it relating to the user section and put into appdata.
What was confusing me the whole time was selecting "connection string" in settings, which didnt allow selection as a USER setting.

SQL Server connection string specified without a computer name? How can that be?

I'm working from a code base I downloaded from a repository, and it is likely that I'm missing a system or local setting.
In Web.Config, I have this connection string:
<add name="Context"
connectionString="Data Source=InstanceName;
Initial Catalog=MyProduct;
Integrated Security=True;
Connect Timeout=15;
Encrypt=False;
TrustServerCertificate=False"
providerName="System.Data.SqlClient" />
(indentation mine)
Normally I would have expected the Data Source to be \\ComputerName\InstanceName or at least .\InstanceName if the SQL Server is on the same host. But here, nothing. The initially uploaded project had a local database, on the developer's machine. I can get the connection to work if I add .\, but I don't understand how only specifying the instance name can work. So, how can it?

The instance name is needed only if you want to connect to a named instance.
If your install of Sql Server hasn't created a named instance then the default for the instance is MSSQLSERVER and you DON'T need to specify that part on the connection string.
However, the computer name part is required but it could be expressed in various form
a point to mean the local computer
an IP address (local or not)
a server name recognized by the DNS system of your lan
the special string (LOCAL)
More info on the Data Source key could be found on MSDN docs for ConnectionString

Could it be that the InstanceName is the name of an ODBC Data Source that already has the target server configured, and the other employees have a corresponding ODBC data source set up?
The other option is that the connectionstring is modified before being passed to a data connector, so "MyMachineName" + connectionstring is happening somewhere (perhaps to separate production and development environments?
Also, double check the App_Data folder to make sure some sort of file-based database isn't being accessed.

In addition to what #Steve has already mentioned local or current machine can also be referred by a special string localhost. Please refer to below post:
What is the sql connection string I need to use to access localhost\SQLEXPRESS with Windows Authentication or SQL Authentication?

using app.config file for connection string, and abstract it from users

I have used app.config file for my winform application , the file is used to store the connection string which is used by all the Forms in my application to connect to a remote MySQL database.
But when I install the application on my customer's PCs, then I want that they could not see the app.config file. Is it possible? How? Please help with code.
Also, is there any other way, to create a connection string which is accessible by all the Forms. Like, can I make a class connection.cs and then inherit it in every Form.
But how to do this? I mean how to implement the code
My main objective is to create just one string for connection, so that , if i change it again and again, then i need not go and change it every Form, instead, i would just change it only in one File , and it would be used by all the Forms
Is using app.config file a good option or making a connection.cs file's a better one?

You don't need to use a connection string from every form, you need a data access layer and then you use it from everywhere, in theory only from another layer called business logic...
A form which needs to load data into a grid, a drop down or some other controls should consume data loaded by lower layers in your application stack.
Read something about 3 tier architecture.

The app.config is always visible on the user machine, so you should not treat any information stored in it as secret.
You really have two options:
Continue to store the connection string in the app.config but encrypt it. This will work fine if its an internal app and security is not to much of an issue. But since the encryption key has to be stored in the app a dedicated hacker could retrieve it.
use a three tier architecture as suggested already. With this the connection string is stored in the middle tier, while your application no longer connects directly to the database but rather through the middle tier. Authentication can then be done with a user name/password per user or by making use of windows authentication. The connection string is stored on a server and only people with acces to this server can look at it and see the DB connection string.

If you just want a simple solutions why not create a class named for example "Connection" in a file connection.cs and let it have a static attribute or property named for example "ConString" which holds the connection string:
public class Connection
{
public static ConString = "your connection string here";
}
Then you can access it everywhere:
OdbcConnection conn = new OdbcConnection(Connection.ConString);
BUT that would only be the quick and dirty way of doing it (although it works). It would be much nicer to create an own Database-Layer - but also much more work.

App.config can't be hidden on users machine, this is what you can do.
You can encrypt the connection string and store it in the app.config. have a look on this article, it shows you how to do that.

Try to define your connection string in program.cs before [statThread] by storing it in a public static string variable like constr etc. Then u can use that var anywhere referencing:
program.constr

C# Connecting to a SQL server with a named instance?

A client of mine has told me the program I made for them won't connect to a SQL server named instance, I have a standard SQL server with no named instance so I'm wondering how I can test this. A named instance connection string look like the one below, could the backslash be were my code fails?
Driver={SQL Native Client};Server=myServerName\theInstanceName;Database=myDataBase;
My code is as follows:
sqlServer=s.Substring(keyword.Length,s.Length-keyword.Length);
FormODBC formODBC=new FormODBC(this);
formODBC.SetSqlServer(sqlServer,dbUsername,dbPassword,database,table);
formODBC.ReadData();
How should I handle the backslash as I suspect this may be the problem?
Thanks

We have SQL servers with named instances.
Examples: myservername\sql2005.
Backslash is fine, in the conection string server name will be "myservername\sql2005", works 100% fine. You can have a "regular instance" on the same server, will be "myservername"
PS just unit test your function making connection string returns "myservername\sql2005".

Also, remember that backslash is an escape character in C# strings. If your instance name is contained in a string variable, make sure you do either:
string server = "myServer\\myInstance";
or
string server = #"myServer\myInstance";

The answer is to ensure your connection string is configurable, and set it to something like:
data source=localhost\msexpress;database=dbname;trusted_connection=true;

There is also the occassional SQL Express edition case where the name is MyServerName\SQLEXPRESS. This can trip up some people because they wouldn't think to specify the server that way.

You can extract your connection string to a config file (note this isn't necessarily secure - that will depend on how their SQL security server is set up and the account your application is running under) - then your client can just add the appropriate connection string for their server to your application's config when deployed.
Notes:
You can create a connection string by renaming a .txt file to a .udl file and running through until you can connect to your/their server.
Your unamed instance can actually be accessed by name - the machine name on which the SQL server is installed

Scott,
At the risk of stating the obvious, have you tried setting up a named instance in your own development environment? I don't actually know the answer to your question but I've never personally run into a solution where testing the scenario that is failing directly didn't help. At a minimum you ought to be able to get better debugging information as to precisely what is failing. Good luck getting this resolved.
Regards,
Chris

OLEDBConnection.Open() generates 'Unspecified error'

I have an application that uploads an Excel .xls file to the file system, opens the file with an oledbconnection object using the .open() method on the object instance and then stores the data in a database. The upload and writing of the file to the file system works fine but I get an error when trying to open the file on our production server only. The application works fine on two other servers (development and testing servers).
The following code generates an 'Unspecified Error' in the Exception.Message.
Quote:
System.Data.OleDb.OleDbConnection x = new System.Data.OleDb.OleDbConnection(#"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + location + ";Extended Properties='Excel 8.0;HDR=Yes;IMEX=1'");
try
{
x.Open();
}
catch (Exception exp)
{
string errorEmailBody = " OpenExcelSpreadSheet() in Utilities.cs. " + exp.Message;
Utilities.SendErrorEmail(errorEmailBody);
}
:End Quote
The server's c:\\temp and c:\Documents and Settings\\aspnet\local settings\temp folder both give \aspnet full control.
I believe that there is some kind of permissions issue but can't seem to find any difference between the permissions on the noted folders and the folder/directory where the Excel file is uploaded. The same location is used to save the file and open it and the methods do work on my workstation and two web servers. Windows 2000 SP4 servers.

While the permissions issue may be more common you can also encounter this error from Windows file system/Access Jet DB Engine connection limits, 64/255 I think. If you bust the 255 Access read/write concurrent connections or the 64(?) connection limit per process you can get this exact same error. At least I've come across that in an application where connections were being continually created and never properly closed. A simple Conn.close(); dropped in and life was good. I imagine Excel could have similar issues.

Try wrapping the location in single quotes
System.Data.OleDb.OleDbConnection x = new System.Data.OleDb.OleDbConnection(#"Provider=Microsoft.Jet.OLEDB.4.0;Data Source='" + location + "';Extended Properties='Excel 8.0;HDR=Yes;IMEX=1'");

If you're using impersonation you'll need to give permission to the impersonation user instead of/in addition to the aspnet user.

Anything in the inner exception? Is this a 64-bit application? The OLEDB providers don't work in 64-bit. You have to have your application target x86. Found this when getting an error trying to open access DB on my 64-bit computer.

I've gotten that error over the permissions thing, but it looks like you have that covered. I also have seen it with one of the flags in the connection string -- you might play with that a bit.

Yup. I did that too. Took out IMEX=1, took out Extended Properties, etc. I managed to break it on the dev and test servers. :) I put those back in one at a time until it was fixed on dev and test again but still no workie on prod.

not sure if this is the problem you are facing,
but, before disposing of the connection, you should do Connection.Close(),because the Connection.Dispose() command is inherited from Component and does not properly dispose of certain connection resources.
not properly disposing of the connection could lead to access issues.