I have a split database design in Microsoft Access. Copies of the front end (w/ forms, queries, linked tables) are distributed to multiple users, while the backend (tables only) resides on the network.
Everything works fine when there is only one user, but as soon as a second user tries to open their copy of the front end, they get an error message saying the backend is already in use.
I've already confirmed that everyone has read & write permissions for the backend.
I've used split databases before and never run into this issue. The only difference is this time I didn't use the Database Splitter utility. I just started with the backend, then created a new database and set up some linked tables. Could that be my problem? Is there a step or setting I'm missing?
In general, this should work.
However, not only do users need read/write, but they ALSO require create file, and delete file rights to that folder.
The reason is that of couse this is pure file based system, so on first open, Access will create a ldb (locking file). This locking file is used to manage (allow) multi-user operations of the file.
If the locking file can't be created (first user to open), then multi-user operations can't be used, and in fact in most cases you get a read-only file.
So, users need quite much full rights. I seen some work with delete rights, but that means the last user out does not allow access to remove (delete) that ldb locking file, and it should be allowed for deletion.
so, create file, delete file rights are also required in most cases for this to work.
It also possbile I suppose that one user launched Access, choose open, and browsed to that file, and opened it exclusive. However, you have a split system, and that should not be possible, but it certainly still possible that someone on the network opened the back end file (that shared file) directly with Access, and used the open exclusive option - which would prevent all other users from opening the file.
As noted, since this looks to be a split system, then I would suggest that users don't have the all important create file rights, and delete file rights to that folder. Without such rights, then as noted, multi-user operations can't occur - you get a read only file in most cases.
So, either users don't have enough rights to that folder, or someone has opened the file with Access, and opened the file "exclusive".
Related
I am trying to split an Access database where I work but I have encountered a few issues that I am struggling to resolve. If I can first explain the problem.
I work for a large multi-national company that has on-site IT support but does not support Access (so no help there)
There are 12 of us working in our section, we have an old and badly designed StockMaster database on the networked F drive. The problem is that it is only set up for single users, we have to take turns using it. We aren't a computer savvy bunch, we tend to run the same named queries on a daily basis
The database is only updated once per day, every morning we get a download from our colleagues in Amsterdam. I do not want to play around with this database as first of all I'm no expert and secondly if I break it, no one will fix it.
My plan is this;
I have created a new Access database StockMaster2 that imports the required tables. Using VB coded modules, is deletes the old then imports the new. Therefore every morning it replicates what is in the original database and it works fine.
My next step is to split the database, create the front end and distribute. This is where I'm having problems.
I created the original front end StockMaster2_fe.accde and placed it in the database folder on the F:\ drive. Does every user get their own copy of the front end? I copied and saved two more front ends (copy and paste in the same folder -> rename) namely StockMaster2_alan_fe and StockMaster2_ryan_fe and tested it. I told Ryan (who sits next to me) to find the front end named after him on the F:\ drive and open it whilst I was in ...alan_fe. We both went to run macros at the same time but he was kicked out as it gave me exclusive access.
What am i doing wrong? Why is it not allowing multiple access?
My problem is that due to strict administrator privileges I cannot download any software or access the command line, so anything that I do must be done in Access itself
I apologize for not seeing this post sooner to end your agony. There are two absolute main issues that must be resolved to get you on the right track. First, and perhaps the most important, is that your file has the name of StockMaster2_fe.accde. The extension, the accde, is the executable version. Design changes cannot be made to that version. The extension should say .accdb to provide you with all the flexibility to alter the database, create one database for back-end tables, and a second database for front-end objects to include queries, forms, reports, macros and modules. If you have the accdb version, then your work will start to get much easier.
Issue number two, if your team is not able to share the database, then that is a sign that the database, when first opening, is opening in Exclusive mode. This option can be changed in the Access Options, in the Advance menu, under Advanced section. Look for Default open mode. It should say Shared to have multiple users operating all at once.
A possible hidden issue that can be happening, is that the database has VBA code which informs the database to open exclusively. With your version of the accde, you will not be able to access that code or change how the database opens.
Let's break this down (only because I finished all my work already...):
My next step is to split the database, create the front end and distribute. This is where i'm having problems. I created the original front end StockMaster2_fe.accde and placed it in the database folder on the F drive. Does every user get their own copy of the front end?
Yes
I copied and saved two more front ends (copy and paste in the same folder -> rename) namely StockMaster2_alan_fe and StockMaster2_ryan_fe and tested it. I told Ryan (who sits next to me) to find the front end named after him on the F drive and open it whilst i was in ...alan_fe. We both went to run macros at the same time but he was kicked out as it gave me exclusive access. What am i doing wrong?
Ensure your back end contains only tables. Access is a "client-centric" database, which means when a query is run it pulls all of the data over the pipe to your local computer, does what it does, and then sends it back. So, make sure the back end has only tables and all the other jazz (macros, queries, etc...) are in the front end. Also, the front end will contain links to the back-end tables. All of your queries/macros/etc.. will reference these links, and not the tables in the back-end DB directly.
Why is it not allowing multiple access?
Also, make sure your table-locking scheme is multi-user friendly. If you're doing table locking, it will cause errors. If you're doing record locking, it probably won't.
My problem is that due to strict administrator privileges i cannot download any software or access the command line, so anything that i do must be done in Access itself.
Shouldn't be a problem at all.
I have a Microsoft Access File that is a shared file. Advanced settings set it to shared by everyone, Default open mode is Shared, No record locks, Open databases by using record-level locking. Enable DDE Refresh and default encryption.
Multiple users can open it at the same time, however if I save I get this message: Microsoft Access can't save design changes because another user has the file open…(etc.)
Any advice on where to begin?
UPDATED INFORMATION:
Apparently the database is already split, so I'm going to do some research in this area. Let me know if you have seen this before and can help though!
By definition, you cannot make design changes when another user is using the file.
Multiple users can access and edit records at the same time. The settings you set, control how strict the locking process is in order to avoid conflicts.
Design changes, not possible, no way!
I have database in the MyApp.app/Contents/Resources folder. I want at least to read data from it in the sandboxed app.
Now I have a lot of "deny file-write-data /Users/user/Desktop/MyApp.app/Contents/Resources/DB/app_db.db" in the Console.
I can't use com.apple.security.temporary-exception.files.home-relative-path.read-write because I don't want to rely upon end user location of the app.
In spite of warnings in the Console my app is working. Is there any entitlement to give access or I should to copy my db to the container during first start?
Even reading from a db can require the DB to write to create locks etc., and you don't have a lot of control of that (you may have some depending on the db). Just follow your own intuition - copy the db on first run to your container.
Also file a radar, it can't harm.
I have a web site which handles files management. User can upload file, add description, edit and delete. What are the best practices for that kind of scenario?
I store files in the file system.
How should I handle deleting of the file? In this case I have to entities to delete: file and entry in database. First scenario is that I delete file and if there was no error I delete the entry from database. But then if the entry from database couldn't be deleted I cannot restore my file. So the second scenario is oposite: first entry from the database and then file. But again, when file cannot be deleted I cannot restore the entry in db. Which approach is better? Or is there any other?
I think the problem is universal for all web programming languages and all databases engines. But let's say that I have MySQL and PHP, so deleting the file from the level of database store procedure is not possible.
I usually find it best to go with doing soft deletes, especially for data in the database.
Doing it this way you could simply put the file in a new location to denote it as being deleted, and mark the entry in the database as being removed. This then allows you to still work with the file if the database delete fails for some reason.
Once you have the file in a new location, you can either backup that location to another place or set something up to periodically delete items from that location.
Here is one possibility.
You could first move the file to a 'Deleted' folder, then delete the entry in the database. If that fails, restore the file from the 'Deleted' folder.
To get rid of the files in the 'Deleted' folder, either do it right after the entry from the database is deleted. If that fails, then you end up you orphan files in a 'Deleted' folder... Depending on you requirement, this might not be a problem.
Another option would be to have a call (maybe on SessionEnd, or a service) that would do the clean up of the database.
I would personally make sure the database gets the priority as it is more fundamental to the system. So i'd make sure the db row gets deleted, then delete the file. If the file deletion fails, i'd make it fail silently. I would then have a cronjob checking against all files if they have their db counterpart, and if not, marked them for deletion, so the system stays clean and coherent.
There is often a garbage collection phase, and in fact your database has something similar called the "transaction log" which it can use to rewind or play forward a transaction.
In the case of your file delete you will have a clean-up process that runs periodically (perhaps manually in the event of a crash, or automatically every so often) that compares what is on the disk with what is in the database and makes an appropriate correction.
In order for any operation to be "atomic" there must be a method of cleaning up in the event of a crash. The key is finding a method that cleans up consistently such that a failure at any point within the "atomic" operation doesn't leave the system unrecoverable.
Vista introduced Transactional NTFS that will allow you to wrap file system operations along with database operations into a transaction that can be rolled back if either failed. This is not in .Net 3.5 and I do not know if it will be part of .Net 4.0, but there is evidence that it works today with a bit of leg work, i.e. by using Win32 calls (see this article).
I know nothing about transaction management in PHP.
I want to make a WPF application that exists in one directory including all files that it needs: .exe, .mdf database, .xml config files, etc.
the application should work no matter what directory it is in so that it supports this scenario:
person 1 executes the application in c:\temp\wpftool.exe
the application reads and writes to the c:\temp\wpftool.mdf database
person 1 zips up that directory and sends it to person 2 via e-mail
person 2 unzips it to c:\Users\jim\documents\checkout\wpftool.exe, the application reads and writes to the same database in that directory (c:\Users\jim\documents\checkout\wpftool.mdf)
person 2 zips the directory up again and sends it back to person 1 to continue making changes on it
What is the best way to create a WPF application that supports the above scenario?, considering:
there should be no hard-coded database connection strings
what is the best deployment method, click once? or just copy the .exe file out of the /release directory?
reasonable security so that users have to log in based on passwords in the database, and if a third person happens to intercept the e-mail, he could not easily look at the data in the database
Some points on the database side:
Assuming the "New user" already has SQL installed, they'd need to attach the (newly copied) database. Besides having sufficient access rights to attach a database, your application would need to configure the call to include the drive\folder containing the database files. If your .exe can identify it's "new home folder" on the fly, you should be able to work that out.
Define "reasonable security". Any database file I get, I can open, review, and ultimately figure out (depends on how obscure the contents are). Can you obfuscate your data, such as using table "A" instead of "Customer"? Would you really want to? The best possible security involves data encryption, and managing that--and in particular, the encryption keys--can be a pretty advanced subject, depending on just how "secure" you want your data to be.
For the database, I would look into using the "user instance" feature in SQL Express. Combined with the |DataDirectory| substitution string support it makes it very easy for your application to get hooked up.
In all honesty I have not deployed a ClickOnce app leveraging this approach myself yet, but I just thought I would bring it to your attention because it's what I would look into myself if I was building something like you described.