The program that i'm developing uses a Microsoft access database, at the moment the database is in the same folder as the application
but i'm looking for a way so that no one can access the database by just navigating into the folder.
I don't know if the database can be attached to the exe or what, but any help on how to go by this is helpful
thanks
The database needs to be accessible by the program, which means ultimately, it can be accessible by the user.
It's customary to store the database in the AppData folder, or in IsolatedStorage.
To help prevent users from accessing the database, slap a password on it. It's far from 100%, but it's a slight deterrent.
If this is really sensitive data, then using a Jet database is not the correct solution, and you should look at SQL Server, etc.
Related
What is the possible solution for this? I force execute the SSIS Job
but the error encountered is
Microsoft jet database engine cannot open the file.''. It is already opened exclusively by another user, or you need permission
What is solution for this I already change the security
This is the flow of the SSIS. The process of this is to update the data of the SQL Server coming from the MDB.
If I'm ever required to use a communal data source like this, especially if the tooling (Excel/Access) takes an lock when someone is just looking at the file, I find it beneficial to copy the file elsewhere for processing.
Before your Update Control Rate data flow, have a File System Task. Define it as a copy with overwrite/clobber/replace from \\server\share\TDMAT TEST\TDMAT.mdb (or whatever the obscured path is) to a local folder that SQL Server Agent/Service Account/SSIS credentialed account has read/write access to. I usually have a folder defined like C:\ssisdata\data_domain\input. So, copy TDMAT.mdb to C:\ssisdata\tdmat\tdmat.mdb.
Then, you have your JET connection managers reference the local file. Away goes your concurrent usage issues. The clever among you might question why we can copy a file that is "locked" but not read it and I can't tell you the why, just that this approach works.
I'm writing a short C# program that will iterate over each user on a given Windows system, check in their local app data folder for a specific directory, and operating on it if it exists.
I'm looking for a good way to resolve the absolute file path to each users' local app data folder. I can use Environment.SpecialFolder.LocalApplicationData but that will only work for the user that is currently running the program.
I know I can cobble together a few different utilities and make a couple assumptions about where a user's local data is usually stored to make it work for 99% of the time (determine a list of all users, go through each one and find/guess where their app data is, etc.), but I was hoping there was a more elegant solution?
I have a C# .NET Framework 4.0 desktop application with Entity Framework as DAL.
When a try to save a data into DBContext on anybodies machine but mine, I recieved an exception
Failed to update database "*.mdf" read only
I keep my DB near .exe file, in folder "DAL/AppData".
How can I allow write access on other machines?
Can I do it programmatically?
I've read that I can place DB into AppRoaming Folder, but this is not my variant.
Thanks in advance.
I keep my DB near .exe file, in folder "DAL/AppData".
Yes. Can it be you mean that this is in the programs file folder, you know.
THe one that windows specs of the last 10 years say is "read only" for normal users?
OUCH.
THer are folders for storing data. There is a SpecialFolders enumeration to get the valid path of every such folder.
How can I allow write access on other machines? Can I do it programmatically?
On a SQL Server, this is done by allowing the other computer to access the server, not the data files. I.e. you connect to the SQL Server on the other machine, which is having the database loaded.
I've read that I can place DB into AppRoaming Folder, but this is not my variant.
First, that would be stupid unless you do actually plan for roaming - SQL shold go into a local folder, never roaming.
Second, "not my variant" is like "Hey, I drive the car against the rules, what can I do not to get speeding tickets". And "following the law is not my variant". Your variant is something WIndows does not care for. Learn how to install your software according to the windows guideline which is VERY clear where changing data should NOT be.
I never see database files in the installation folders of random programs, yet they obviously have one. My question is how do they do it?
EDIT: My database can be either on SQL Server, MySql, or Access I'm not bothered, however I would like the client to not have to download SQL Server or any other programs in order to be able to use mine.
You never see database files in the installation folders because installation folders are meant for programs, not for data. The data go into the appdata folders, such as "C:\Documents and Settings\User1\Application Data\Company1\Application1" or "C:\Users\User1\AppData\Company1\Application1" depending on your OS.
I never see database files in the installation folders of random programs yet they obliviously have one
If they are oblivious to database files then they don't need them. That is why you don't see them.
You can place the database file in Hidden Mode so that user can't see it until and unless he has Show Hidden Files option true
Or instead of placing database file along with exe you can place in dedicated application directory like C:\users\username\appdata\yourapp\
My suggestion would be to store your own database as a flat XML file (for example, a plain .NET DataSet saved to file via DataSet.WriteXml ) then apply your own fixed encryption to that file. the key to encrypt/decrypt will be inside your program code and need never be altered. By storing your own data as XML you wont need a client. At the start of your program, Read and decrypt your datafile into memory, then save and encrypt out when needed.
I have a program in C# that uses an MS Access database and I'm using OleDb to connect and do queries on that database. My issue is that I have some sensitive info in the database and I don't want it to appear as an Access DB. I changed the extension, but when I open it, it still creates the .ldb lock file used by Access. I want to have the DB not create that lock file.
I have read many posts on the issue and it sounds like if I open the DB in Exclusive mode, it will not create that .ldb file. However, so far, I have not found any connection string for OleDb that lets me specify Exclusive access to the DB. The OleDbConnection object in C# has no "Mode" member either, so setting exclusive access that way is out of the question.
If anyone has any connection strings that can open the DB in Exclusive mode, or if anyone knows another way to avoid creating the .ldb lock file in Access, the help would be much appreciated.
http://www.connectionstrings.com/access has an entry for Ecxlusive mode.
I would recommend using SQLite or another non-access option if you want to avoid lock files.
Trying to avoid the lock files is difficult at best. Even if you open the file in exclusive mode, JET creates these files at times.
If you're trying to store sensitive data, and you want to "hide" the type of file, another good option is VistaDB. It's a single file database, but allows full DB encryption. This would probably be a better approach than just trying to mask the fact you're using JET.
You can't really hide that it's an Access database. Anyone can open the file in a hex editor (or even just notepad) and see a string like "Standard Jet DB" (Office 2000/XP/2003) or "Standard ACE DB" (Office 2007) staring right at them. Even if they don't know what that means Google will tell them soon enough. You use could a less-common database, but they will have similar weaknesses.
If you really want security, you're going to have to encrypt the database file and use an engine that will let you keep a decrypted version in memory (IIRC sqlite supports this, or will soon) or use an engine that supports encryption natively. Even then, you can have problems if the ram is paged to disc or if another process "sniffs" your app's ram.
A late update, but my attention was drawn back here today and I wanted to add that just about anything but Access will require you to distribute the engine with the application. You need to also take care that the files for the engine don't give it away as well. Access gets a pass because the engine is already part of windows. You might also try something that's open source, so you can re-compile it into your main application file.
I have several databases with the Exclusive flag set, and I still get .ldb files created each time I open one. If you are really worried about security it's time to move to a 'grown-up' database.
Install SQL Server 2008 Express, use upsize wizard in Access, point to your Express instance.
You could also potentially use Sql Server Compact to do this. It is free and part of Visual Studio. It is actively used by Microsoft in quite a few products, including Windows Live.