We Keep Coding

Portability of an MDF database file across different Windows machines

Here's the context: I'm writing a C# application that connects to a local database file (MDF). The application's GUI enables the users to do various queries and view results in a Grid View control. The MDF file is distributed with the application and can be considered an immutable (or read-only) resource i.e. not meant to be updated or modified by the end user.
The application is currently in alpha stage and has never been deployed. The source code, along with the MDF database, is source-controlled (via Perforce), so when other developers in my team synchronize their workspace, they get a copy of the MDF database (and LDF log) along with the code. No server connection is involved, all queries are made to the local DB copy using (LocalDB)\MSSQLLocalDB and the default Windows Authentication.
Here's my problem: The MDF file cannot seem to be used anywhere but on the machine it was created on. If another developer builds my app on his computer, the connection to the local database fails with a generic SQL Server error 5171. However, the MDF file is not corrupted and is a primary DB file, so the error is elsewhere.
Here's what I tried:
Verified that SQL server version is the same on all machines, so it's not a compatibility issue
Connection string used in the application is dynamic (i.e. adapts to the location of the MDF file on the computer) and formatted as: Data Source=(LocalDB)\MSSQLLocalDB;AttachDbFilename=C:\MyLocation\DatabaseFile.mdf;Integrated Security=True;Connect Timeout=30
Used same Windows login on all computers, to no avail (still gives error 5171)
Verified DB options with SQL Server Management Service: Restrict Access is set to MULTI_USER
The only workaround I found is to re-generate the whole database on the machine but that's not acceptable: can't one just connect to the MDF file one gets from Perforce and be done with it? Thanks.

Sorry to answer my own question so late after it was initially posted, but here it is: the solution is to make sure the MDF file is saved in Perforce as binary, not as text.
That solved the data corruption problem right away and the MDF database finally became portable across machines/users without any further issue.

Flat File Destination Failed the pre-execute phase. Cannot open the datafile

I am executing a SSIS Package from a C# WinForm project. It executes and runs about halfway when it tries to create/write a file (An Expression in the Flat File Manager).
When I check the SSISDB Catalog on the SQL Server, I see the following errors for the package:
Flat File Destination failed the pre-execute phase and returned error
code 0xC020200E.
PO Header:Error: Cannot open the datafile "\Server\path\Admin Shared
Folders\Information
Systems\Projects\projectPath\filepath\636943168325507712-1070-15175.txt".
Based on the path and filename, the expression resolved fine. When I run the SSIS package directly it runs fine, so it appears to be a permission issue.
I am using Integration Services (MS SQL Server 2014) and right now I am using windows authentication in my connect string:
Integrated Security=SSPI;
However, the group who will be using the app will not have full permissions, so a specific user account will be created in SQL Server that I will use to connect. That said, assuming that this is a permission issue, how does the SQL Server account need to be created / what permissions and considerations need to be applied? What other permission issues/considerations need to be taken into account?
ie, we have no idea how to create the account to make this work and need help!

I think you are ask for run with SQL agent and hit permission issue, you can do this, in Windows service there are a service name call SQL Server Agent, and Log on with a special account, likely you create a individual account, and give this account to your folder permission.

Make sure that SQL service account can access to this path and has needed permissions:
Configure File System Permissions for Database Engine Access

Windows service install doesn't have correct privileges

I have a service that I have created for Windows. The service works fine. The problem I am having is a permission issue. My service accesses a .mdf SQL Server database file that is created when the service is installed (using Installshield VS 2012).
The service itself is running as user. When I install I input my credentials and I can successfully start the service. The service starts fine. However, when I get to the part in my code where I have to open the .mdf I get an error because the database log file does not exists and the service does not have permissions to create it.
The only way I can fix it is by adding my username or authenticated users for example to the security section of my program files folder. This allows the SQL Server .log file to be created and my service continues running.
What is the best solution to getting around this? Basically I want to be able to run the service and local system and it have the privileges to install and create the .mdf.
Thank you for the help.

You should create the database log file during the installation. You can run custom code during the installation to do that (the code may be similar to what triggers creation of the log file in your regular code). That will use the user with elevated permissions so it will work well and is correct from the security point of view (all administrative tasks should be done during the installation in this case).
It's better not to add permissions for a normal user to SQL Server data folder as that will lower security.

Make MS-Access database file accessible to C# program from LAN network

I have a C# program that connects to MS-Access local file using:
dbConnection = new OleDbConnection("Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" + sPath);
dbConnection.Open();
where sPath is the local file path.
The program does select, insert and update sql operations. I want to deploy the C# program to another computer wih is on WiFi LAN to access the same database. I assume I only have to provide correct Path? or anything else? Will the database allow both read and write operations?

RE: sharing the database over the network
Yes, essentially all you really need to do is put the .accdb (or .mdb) file in a shared folder and tell your C# program where to find it.
Notes:
Each machine needs to have its own copy of the Access Database Engine installed. If Access is not already installed on the machine then you can download the Access Database Engine installer here.
For multiple concurrent users to access the database all users must have sufficient privileges to create and modify the associated .laccdb (or .ldb) lock file in the folder where the database file resides. That is, all users need more than just read access to the folder. (That is a common mistake people make when they first deploy an Access back-end for multiple concurrent users.)
RE: WiFi
The ACE/Jet database engine relies on a solid network connection to the database file, so any intermittent network glitches resulting from a weak WiFi signal are going to cause problems. In the early days of WiFi that was a common cause of errors in many database applications (including, but not limited to, Access databases). WiFi technology has improved over the years, so this is less of a problem than it used to be, but do be aware that flaky WiFi can cause errors (and even corrupt the database file if you are unlucky).

How to access the database Remotely through IIS?

I have used the ASP.net with C#. I want to access the SQL Server database through web server. When executing my application from development area it's working but after deploy the application to the IIS server it shows the following exception:
CREATE DATABASE permission denied in database 'master'. An attempt to
attach an auto-named database for file D:\newtest\newtest.mdf failed.
A database with the same name exists, or specified file cannot be
opened, or it is located on UNC share.
I have used the following connection string to attached with database
Data Source = .\\SQLEXPRESS;AttachDbFileName=databasepath; Integrated Security=true
How do I access the SQL Server database Remotely through IIS?

Although the answer by Sanjay is correct, it doesn't really explain why you're getting the permission denied.
Code running in ASP.NET / IIS runs as a specific user, as defied in the worker process' config. For IIS 6 [Server 2003] (and below, I think) the default was NETWORK SERVICE for IIS 7+ [Server 2008], the default behavior is to run as a special application pool user IISAPPPOOL\yourAppPoolName.
If you grant the requisite permissions on your database for the correct user account(s) -- you should be able to get around the error and still use integrated security.
As an aside, it is generally a good idea to give the most restrictive (yet still operable) set of permissions on your database. CREATE DATABASE requires a pretty high permission level (I don't remember what off the top of my head.) If you grant that to your IIS application, you run a significant risk of allowing a less than honorable user taking control of your database system and wreaking havoc on it.

Hey Create Credential with SQL server and update your config file
connectionString="Data Source=Abcl\SQLEXPRESS;Initial Catalog=master;User ID=sa;Password=pwd12" providerName="System.Data.SqlClient"
if your are using db file like mdf
Pls use like this
connectionString="AttachDbFilename='C:\Documents and Settings\nmartin\My Documents\PS_Upload\TimeTrack\src\TimeTracker\TimeTrack\App_Data\ASPNETDB.MDF';Integrated Security=True; User Instance=True"

They key is that you've used Integrated Security=True in your conneciton string.
When you run your project in your development environment, the web application usually runs as your local user account. Furthermore, your account is usually a privileged user (admin) on the local SQL instance.
On your deployment server, IIS usually runs as a local machine account (or an account provisioned for your AppPool). That account usually doesn't have any special privileges on the SQL server instace.
As debracey points out, you normally don't want to have your app's SQL privileges high enough to cause any harm (even if it's an honest mistake on your part). One common pattern to avoid tihs is to have two separate SQL accounts for your app:
A high-priviledged account for creating and modifying your database schmea (e.g. db_owner role)
A limited-privilege account for accessing your database while your app runs (e.g. db_datareader and/or db_datawriter role)