My application does basic CRUD operations over an external .mdf file. The database file is created separately in SSMS. On my PC, everything works perfectly fine. When I install it on someone else's computer, it refuses to connect to the database. The other PC also has the same database at the exact same location.
The connection string I am using is (in app.config):
conString=Data Source =.\sqlexpress; Initial Catalog = dbName;
Integrated Security = True; Pooling = False
In my code:
dbConnection = new SqlConnection(Settings.Default.conString);
The other PC has SQL Server installed as well. Tried going through almost all the results but almost all of them suggest either
Adding the existing database with the project. I can't seem to do that because when I try that I get an error:
permission denied
I can't rewrite the whole code with a service based database pre-attached to it.
Related
I'm developing Windows Desktop appication(C# WPF) with Microsoft localdb(.mdf) and I want that users of my software can carry their localdb (.mdf) file when they move to other places(computers). The localdb (.mdf) file is created on the first computer.
To test my application, I copied my localdb file from computer A to computer B and attached with below code successfully.
string attach_greendbnameQuery = string.Format(#"EXEC sp_attach_db #dbname = N'greendb_{0}', #filename1 = N'{1}\greendb_{0}.mdf'", textBoxGreenLogin.Text, Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData).ToString());
SqlCommand attach_greendbnamecomm = new SqlCommand(attach_greendbnameQuery, check_datadbinmasterConn);
attach_greendbnamecomm.ExecuteNonQuery();
And I could read and write data into the moved localdb file.
However, when I run backup command on this database, exception occurs like,
'Unable to open physical file, Operating system error 32, process cannot open the file because the file is in use by another process'
If I enter Server Management Studio- Security-KayLee-PC\KayLee- User Mapping,
the users of all other localdb are 'dbo' but only the user of manually moved database is KayLee-PC\KayLee and only 'public' is checked and all other database roles are not checked including db_owner. (I always start(login) Windows(O/S) with KayLee-PC\Kaylee account)
I tried to make all roles checked to database roles even to server roles but failed.
Even, I tried to drop the user KayLee-PC\KayLee through below code but the exception message show as,
'User 'KayLee-PC\KayLee' does not exist in current database'
If I click the database in Server Management Studio, the current database status is not changed to clicked database and subtree nodes(like Table, Security and so on) are not displayed with message 'cannot access to the database' eventhough if I click other databases, the current database status is changed to clicked database.
Also, I tried to change the owner of the localdb(database) through below code but it seems the execution failed with result '-1' with 'sa' and when trying with 'KayLee-PC\KayLee' which I always login to Windows O/S, error message is like 'KayLee-PC\KayLee is already an owner(exist) of this database'
SqlConnection dbownerchange_Conn = new SqlConnection();
dbownerchange_Conn.ConnectionString = dbownerchange_ConnectionString;
dbownerchange_Conn.Open();
SqlCommand dbownerchange_comm = new SqlCommand();
dbownerchange_comm.Connection = dbownerchange_Conn;
dbownerchange_comm.CommandText = "EXEC sp_changedbowner 'sa'";
dbownerchange_comm.ExecuteNonQuery();
dbownerchange_Conn.Close();
Simply, If we need to move(copy) Microsoft localdb file to another place(computer), how can I do this successfully?
Must we detach before move the localdb file? If so, I'm worried there're always people who don't follow guideline by running detach function.
I've tried several scenarios to understand how SQL server is working. The conclusion is we need to detach first and re-attach to same or different machine(computer). Then, I could have been successful to move to another computer.
However, a single process of backup and restoring localdb to another machine(computer) doesn't work. Furthermore, if we detach localdb(database file .mdf) first, SQL server no more recognizes the localdb database and we cannot run backup command for the localdb.
Conclusively and simply, if we want to move localdb (microsoft database .mdf file) to other local server(computer, machine), we're needed to just detach the localdb from master database in computer A and copy the files and re-attach to another master database of computer B.
Hope this helps someone else..
I've got this scenario: I developed a C# application which connect to a mdb file (Access 2003) through OleDBConnection (engine = Microsoft.Jet.OLEDB.4.0). This mdb file has some linked tables in another mdb file in the same directory. Everything works perfectly in the local environment, the query retrieves data from linked table even if I connect only the main mdb file. A simplified schema could be:
my application in the local machine --> C:\mydir\main.mdb --> C:\mydir\linked_tables.mdb
But this application should work in some host computers of a local network. And the mdb files are stored in a server in a shared directory. Well, when the application is running in a host I set the path as follow:
\\myserver\mydir\main.mdb
The connection works. The problem happens when I launch a query which tries to get data from linked tables. It tries to find the linked table in C:\mydir\linked_tables.mdb, but this path is on the server, not in the host.
Is there a way to tell him: if the path of the main mdb file is \\myserver\mydir\main.mdb you must (automatically) get the linked tables on \\myserver\mydir\linked_tables.mdb?
Thank you
I solved with another connection. I mean: for each mdb file I use a different OleDBConnection.
OleDbConnection MainConn = new OleDbConnection("\\myserver\mydir\main.mdb");
OleDbConnection LinkedTablesConn = new OleDbConnection("\\myserver\mydir\linked_tables.mdb");
Not so elegant, but it works. If I have to do some join of tables located in different databases, I manage them with some generic collection objects.
newbie here.
I have a local db in my program. Whilst I was developing the program I used the SQL
Connection string :
SqlConnection sconn = new SqlConnection(#"Data Source=.\SQLEXPRESS;AttachDbFilename=C:\Users\leemk_000\Documents\......Integrated Security=True;User Instance=True;");
Now If I want to load this program onto a different computer I am sure that this connection will no longer work simply because it will still be looking for Users\Lee_000\
I have tried to remove Lee_000 but I get this following error:
An attempt to attach an auto-named database for file C:\Users\Documents..... failed. A database with the same name exists, or specified file cannot be opened, or it is located on UNC share.
What can I do to get a connection string to work on different computers.
With many thanks
The whole User Instance and AttachDbFileName= approach is flawed - at best - especially when you want to share your database amongst multiple clients!
When running your app in Visual Studio, it will be copying around the .mdf file (from your App_Data directory to the output directory - typically .\bin\debug - where you app runs) and most likely, your INSERT works just fine - but you're just looking at the wrong .mdf file in the end!
If you want to stick with this approach, then try putting a breakpoint on the myConnection.Close() call - and then inspect the .mdf file with SQL Server Mgmt Studio Express - I'm almost certain your data is there.
The real solution in my opinion would be to
install SQL Server Express (and you've already done that anyway)
install SQL Server Management Studio Express
create your database in SSMS Express, give it a logical name (e.g. YourDatabase)
connect to it using its logical database name (given when you create it on the server) - and don't mess around with physical database files and user instances. In that case, your connection string would be something like:
Data Source=.\\SQLEXPRESS;Database=YourDatabase;Integrated Security=True
and everything else is exactly the same as before...
If it's a local db you should be placing it within the app folder and carry it with the app right?
Put the database in the App_data folder of your app and use that in your connection string
<add name="YourConnectionString" connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\yourfile.mdf;Integrated Security=True;User Instance=True" providerName="System.Data.SqlClient"/>
You need to use a database server and let your users use it via your connection string like this;
Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;
"myServerAddress" should be the ip adress of your server machine.
I have created a desktop application with SQL Server 2008 as backend. I want to use this database from my application that is installed on a number of machines.
What are the requirements for that application to connect to the centralized database.?
It is pretty simple, You want the architecture as Client-Server model were the server has the database .Hence you need to have MS SQLserver 2005 or higher versions and create database connect it to sqlserver. Grant permission for the clients to access the database.
From visual studio side:
Add the above created .mdf(database file) as the new data source.
Data-->Add new Data Source , and follow the steps in the wizard[p.s the type of connection has to be sql sever type ]
while doing this a connection string will be created by VS. Use tht connection string to access from the client side.
This link would be useful : http://msdn.microsoft.com/en-us/library/sxds9ett(v=vs.80).aspx
To keep the connection string in its resources, ofcourse.
Resources are:
Doubleclick on project's Properties (at solution explorer).
Then Settings tab.
If there is no default setting file, create it by clicking the long link label.
Add a setting like "ConnectionString" with the value like "Data Source = ..." whatever.
Then you can run your sql scripts like:
SqlConnection conn =
new SqlConnection(Properties.Settings.Default.ConnectionString);
And go on.
Using VC# I've created a staff management app that, upon its first run, is expected to query the user for the path to a (.mdf) database which will reside on a remote computer. A resulting path may be something like
string dbPath = #"P:\remoteComputer\public\StaffTool\ExamplePersonnelDatabase.mdf";
Then I'm placing this string into a connection string template as so:
string dbConnectTemplate = #"Data Source=.\SQLEXPRESS;AttachDbFilename={0};Integrated Security=True;Connect Timeout=30;User Instance=True";
string dbConnectionString = String.Format(dbConnectionTemplate,dbPath);
Then I'm attempting to connect to the database LINQ to SQL style
ManagementDBDataContext db = new ManagementDBDataContext(
dbConnectionString);
At this point, an error pop's up stating that
The file "P:\remoteComputer\public\StaffTool\ExamplePersonnelDatabase.mdf" is on a network path that is not supported for database files.
An attempt to attach an auto-named database for file P:\remoteComputer\public\StaffTool\ExamplePersonnelDatabase.mdf failed. A database with the same name exists, or specified file cannot be opened, or it is located on UNC share.
As I am relatively new to databases, I completely do not understand this message. And obviously, the file is not on a UNC share.
Any ideas?
Jim Lamb recommended that I connect to an instance of SQL server running remotely. Considering that I'm using LINQ to SQL, what refactoring do I have to do to make this happen? Other ideas still welcome - especially "push this button and everything will work" solutions.
Another clue: A coworker said that there used to be some way to work through Control Panel->Administrative Tools->Data Sources(ODBC) so that a remote database could be viewed from my computer as if it was local. The coworker didn't know any more details besides this.
You are attempting to connect to a database file on another machine over a network connection, which isn't supported by SQL Express. You'll need to make a local copy and attach to that, or connect to an instance of SQL that's running on the same machine as the MDF file.