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.
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.
Hoping in can find someone who is familiar with this scenario. I've not touched Paradox in over 12 years, and most posts I find on the subject are 5+ years old.
I have created a C# application to read a Paradox .db file using OLEDB and the Borland Database Engine (BDE) to retrieve a transaction code. I have no control over the Paradox system, my only access to it is through a UNC path to the .db files. The original developers of the system are no long in business, so there is no support. Hence the reason I'm having to "hack" a solution to my customers problem.
For development I copied the relevant .db files locally and had no problem accessing them. However when I try to access the live files, the error I get is that they are under the control of a different .LCK file. Deleting the .LCK file solves the access issue, but obviously that is not the solution.
The existing system has the "server" a Win7 machine, and 3 clients running what I assume is the Borland / Paradox application.
Is there a way to configure BDE (or some other workaround) to allow access to the live files using the existing .LCK files? I've tried with different values in the BDE "NET DIR" setting.
My only other option that I can see is to load the entire .db file into memory, (I have code that does that without BDE) then find my transaction value, which is not ideal as that takes around 15 seconds, and as this is a Point of Sale application, it needs to be much faster. Select statements via OLEDB work perfectly in this regard.
I have a Microsoft SQL database that is currently connected to a winforms C# application, it works fine on the single computer, but i would like it to be usable on a CD for any user.
I tried putting it in as a localDb but for some reason the database is duplicated and put into the bin folder, it causes multiple issues in recording data, for instances i save user ID 5 it saves in bin but never makes changes to the real database. Then next i go to create it, the user ID changes to 7 with user 6 not visible in either two databases (yes it is auto incremented by 1)
Any suggestions or best methods on making a database useable and readable via CD if the winform application is also on the CD
I have not tried this my self, but according to the documentation SQLite supports read-only databases.
If the file is read-only (due to permission bits or because it is located on read-only media like a CD-ROM) then SQLite opens the database for reading only. The entire SQL database is stored in a single file on the disk. But additional temporary files may be created during the execution of an SQL command in order to store the database rollback journal or temporary and intermediate results of a query.
see https://www.sqlite.org/c_interface.html
.NET SQLite providers are available here:
https://github.com/praeclarum/sqlite-net
http://system.data.sqlite.org/index.html/doc/trunk/www/index.wiki
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.
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.