In one of my Stack Overflow questions about MS Access front-ends, an SO community member suggests that each user should have their own copy of the .MDB or .ACCDB front-end file:
Don't put the database on a network drive and share it with users.
Give each user their own copy.
Is this necessary? What are the problems associated with multiple users accessing the same file?
The estimated number of users for my future front-end is currently 5, possibly growing to 10-20.
It is not necessary if you mark the file itself as read-only (right-click, properties, bottom-left mark) as all temp data then will be forced to real temp files and the file, per definition, cannot be corrupted.
However, the user will be warned about this with a yellow banner when he/she opens the file.
If they can't live with that, you can create a shortcut to copy and launch the frontend which will provide "automatic" updates of all users' frontends at relaunch.
A script that performs this (you may reduce it somewhat for your scenario) can be found here:
Deploy and update a Microsoft Access application in a Citrix environment
Related
I have an MS Access front-end (Oracle back-end) that has 2 linked tables, 2 MS Access queries, and 4 reports.
I've noticed that the .accdb files (stored on users' desktops) get bigger over time. They start out at under 1mb after a compact, and end up being 10-20mb after a few months use.
Why is this? There isn't any data stored in the file, so why does it get bigger over time?
It's because (some) temporary data are created in the frontend. It shouldn't matter at all, except if it disturbs you.
You can avoid that completely by making the frontend file read-only, but usually it pops a warning message when the user launch the frontend. It will force temporary data to be written to separate files.
Another method is to set the frontend to compact before closure. However, that sometimes fail, thus causing more trouble than advantages.
The definitive method to avoid it, is to copy a fresh frontend to user. The user clicks a shortcut to a script that copies the file from the server to a local folder and launch it from the local copy. A script to handle that can be found here:
Deploy and update a Microsoft Access application in a Citrix environment
I had the same problem and this is what I learned :
Front-End file size can increase because of a lot or reason and it is important to verify what is the cause. (Memory Leak, Image Management etc)
A good deployment architecture is important and will help avoid the file to increase over time:
Good Example of deployment architecture
If it is too late and your file have already increased, you can normally return close to the original size with the "Compact and Repair Database" functionality:
Open Access in design mode
Access Section "Database Tools"
Select "Compact and Repair Database"
The company is using an old Delphi software, that uses a .mdb file as database.
I can't change the way the application works, I don't have it's source.
We are facing many problems such as:
Lock problems
When an user adds an entry, it doesn't update the database, it only appears locally
The lock problems are solved for now, currently, the problem is that only the first user that connects to the .mdb can edit, add and delete entries, the other users do that to, but the changes are not applied to the db, it seems it's only apply locally, on the user machine.
My question is, is .mdb supposed to work with many users over the network(3~4 people)?
What Is there anything I can do to make this software works well with the .mdb file, with many users?
Remembering that I cannot split the .mdb, as I cannot edit the Delphi application.
You don’t mention that if this in the past work fine in a multi-user environment. However, keep in mind that users MUST have full read/write AND ALSO file create and delete rights.
The reason for the create and delete rights is that because this is a “file based” system without a server process, then a locking file is created in the same directory as the back end mdb file. When the first user opens the file, and they don’t have FULL RIGHTS to the folder, then the file is opened in exclusive mode, and all additional users will be read only. This thus explains your symptom of first user in, but additional users don’t work. (the additional users will be read only – and obviously the Delphi software does not detect this problem). So you can view data – but no saving of data can occur.
So you need to ensure that all users have the ability to create that locking file. It is created by the first user, and any additional user opening the back end ALSO needs rights to that file (so don’t by mistake have permissions to the folder set on a per user basic, since then the first user in will cause JET to create the locking file but with permissions to that first user!. Once again this will mean additional users will be read only. So additional user MUST be able to open the locking file, and the first user in MUST be able to create the locking file. In fact open Access will open the database (mdb) as exclusive and prevent multi-user when the locking file cannot be created.
When the last user leaves the database (or in your case leaves the Delphi application), then the back end file is closed and ALSO THE locking file is deleted by the database engine (JET)
So this sounds like your IT folks did not give wide open permissions to the back end folder. You “can” run the database with file delete rights removed, but I much suggest that the locking file being re-cycled is also a good thing since over time it can become damaged etc.
So based on your symptoms, this is a VERY common occurrence in Access, and this problem is fixed by giving all users sufficient permissions to create files in the same folder as the back end. (and not permissions based on per user).
ALL users must be able to create + open + use that locking file created by the first user opening the mdb file. This locking file creation is automatic and managed by the JET database and not the Delphi program.
Yes, it can work with x ppl on a network.
Make sure the Access database is set to open in shared mode, which is the default setting.
Tools menu, click Options.
On the Advanced tab, under Default open mode, click Shared.
Use this Powershell script:
Get-SmbOpenFile | Where-Object -Property ShareRelativePath -Match ".mdb" | Close-SmbOpenFile –Force
I'm creating an Access 2010 database and would like some clarification when it comes to concurrency and security. What I would like is upon starting the app only a menu form to be displayed with several buttons including a login button. Most buttons would be disabled until after the user logs in at which point based on their permission group; Viewer(Deafault), Worker, Editor, Admin.
Also, Admin should be the only one to be able to see the access database while the others are restricted to seeing the forms only.
I was just testing the default concurrency implementation but saving my database to a shared network and having myself and a co-worker try to access it. Found out if one accessed the database it locked it from others, and if we both tried at the same time it became read-only.
So I'm just looking for tips on how to start this.
For an Access database all users must have as a minimum read, write and modify permissions on the folder in which the database resides. This is because MS Access creates a lock file and if the second user does not have permissions to modify the lock file, the cannot get access to the database. Delete permissions may also be useful, to remove the lockfile when they are the last person out.
One of the best practices as specified by Microsoft for Access Development is splitting Access application into 2 parts; Front End that hold all the object except tables and the Back End that holds the tables.
The msdn page links there to the article Splitting Microsoft Access Databases to Improve Performance and Simplify Maintainability that describes the process in details.
It is recommended that in multi user environment the Back End is stored on the server/shared folder while the Front End is distributed to each user.
That implies that each time there are any changes made to the front end they need to be deployed to every user machine.
My question is:
Assuming that the users themselves do not have rights to modify the Front End part of the application what would be the drawbacks/dangers of leaving this on the server as well next to the Back End copy?
I can see the performance issues here, but are there any dangers here like possible corruptions etc?
Thank you
EDIT
Just to clarify, the scenario specified in question assumes one Front End stored on the server and shared by users.
I understand that the recommendation is to have FE deployed to each user machine, but my question is more about what are the dangers if that is not done.
E.g. when you are given an existing solution that uses the approach of both FE and BE on the server. Assuming the the performance is acceptable and the customer is reluctant to change the approach would you still push the change? And why exactly? For example the danger of possible data corruption would definitely be the strong enough argument, but is that the case?
It is a part of follow up of my previous question From SQL Server to MS Access 2007
The only drawback to leaving the individual user specific copies of the FE on the server is network performance. It won't make a difference as far as data corruption.
But you shouldn't share a FE between multiple users. This is prone to corruptions on the FE and other weirdness. Each user should get their own copy of the FE. Also you can't replace it with a new copy while users are using it.
A client was running for years with the FE on individual user folders on the file server but running msaccess.exe in a Citrix cluster. The IT staff didn't want to have anything updating the local hard drives of the Citrix cluster server systems.
As far as deploying the FE see the Auto FE Updater at my website. Huge changes coming in the next week to make it much, much easier for both initial server install and easier user initial install.
To keep the front-end on the server would more or less defeat the purpose of splitting the database. Putting the front-end on the desktop reduces network traffic since the application is not retrieved for each use, and allows the front end database to contain tables with data that is private to each user for storing settings or temporary data.
If you wish to avoid data corruption, it is important that each user should have their own copy of the front-end. Allen Browne offers more details on avoiding corruption in this article
There are a number of utilities available to update the front-end version on the desktop as required, or you can even write such a utility yourself.
I agree with the others. Keeping the fe on the server is not recommended. Just put a batch file on your server that does the push. When you have an update send a shortcut to the batch file via email. That is one of many solutions. Once you set it up it is not a problem.
Seth
As an Access 2007 Programmer using a Front End (FE) that is linked to a Back End (BE) database (a.k.a. Split Database) I have done both of the above. Sending an updated FE to users has other overhead, esp if third party controls or applications are used.
As for Citrix, back in Access 97 days, a Citrix manager was able to allow me to put one copy of the FE in a server file location. It would create a new instance for each user that logged in. We were able to use over 50 users with out any impacts. I must qualify this by saying the Access VBA code used efficient updates and transactions with roll-backs rather than just simple Select statements.
My problem today is Access 2007 running on a Citrix server (Windows 2003).
When I am the only person logged into Citrix, the application ( I picked a large complex report that creates a custom Excel spreadsheet via automation for the test) it runs within 1% as fast as running the FE from my XP workstation, and linking to the BE on the Citrix server hard drive.
But, when two or three people log into the Citrix Server, the same report takes three times as long. However, while two or three people are logged into Citrix, I can run my FE from my XP workstation and it runs exactly like the single-user on citrix.
A FE posted on a shared networked drive, shared by two or three users is NOT advised for this same reason. Access FE are not designed to be shared (* I will spare the details*). That is why people put a FE on each workstation and share one database (BE).
What I find lacking in Citrix is some good step-by-step "how-to" run Access FE on Citrix. Ideally, a single file could be posted. When a user loggs into Citrix, Citrix should make a copy of the FE and assign the resources (for Access) to that user's login.
I think this is exactly what MS Office does automatically or at least has instructions on how to do it.
If such a document exist, please post it. A programmer like myself would love to hand it to the Citrix Administrator. It would solve a lot of problems.
I maintain an ms-access application splitted to frontend and backend files.
The frontend file is in the users conputers.
The backend file is in a shared folder in the server.
What is the lowest permissions required?
can I give some of the users only read-only permissions in that folder? (or hide it from them in some other way) but still enable them to view the data?
How should I give the best security to the data file and to the folder containing it?
Unfortunately, the lock file (ldb) must be created, updated and deleted. If a user with insufficient permissions opens the database, it will be locked for all other users, therefore all your users need Read/Write/Delete permissions on the back-end.
EDIT #1
The lock file must be created every time the database is opened, this includes via linked tables, and deleted when the database is closed. If a lock file exits and the database is closed, it indicates a problem has occurred. You will also run into problems with compact and repair if it is run with insufficient permissions.
Edit #2
Security for Access is quite a large subject and depends to a great extent on your environment and requirements, for the back-end, it ranges from a database password, which is tissue thin, but quite suitable for most offices, to Access security, which can be complicated and has been dropped in 2007. Here is a link http://support.microsoft.com/kb/207793 for a download for the Microsoft Access Security FAQ for versions < 2007.
Information on security for 2007 can be found here http://www.microsoft.com/technet/security/guidance/clientsecurity/2007office/default.mspx.
Many have suggested that you must give FULL permissions to users, but this is not true. You need only give them MODIFY permissions -- you can deny them DELETE permission, which is a good idea, as it prohibits the users from "accidentally" deleting your data file.
It is true that for a user with DELETE permissions, the LDB file will be deleted on exit when that user is the last user exiting the database. But it is not required that the LDB file be deleted -- indeed, in Access 2 and before, the LDB files were not deleted on exit, but just left there hanging around. This generally has no downside, but occasionally the LDB file gets corrupted and causes problems and really does need to be deleted and recreated afresh.
What I do is have two classes of database users (as defined in custom NT security groups specific to my Access application(s)) -- DBAdmins and everyone else. The DBAdmins have FULL permissions, everybody else only CHANGE. The result is that any time a DBAdmin exits as the final user, the LDB is deleted. This setup works really well, and I've been using it for well over a decade.
Using a hidden share for your back end is really only "security by obscurity," and not really worth the effort. Sophisticated users can figure it out through any number of methods (depending on how you've locked down your front end):
view the MSysObjects table and find
the CONNECT string for the tables,
which will identify the hidden
share.
examine the results of
CurrentDB.TableDefs("name of linked
table").Connect in the immediate window in
the VBE
Now, if you've properly secured your app using Jet user-level security (and it's very easy to think you've secured your database and find out that there are holes, simply because it's really easy to forget some of the crucial steps in the process), they won't be able to do this, but even if you have, Jet ULS security is crackable (it's pretty easy to Google it and find cracking software), so is not really something you should depend on 100%.
Yes - it resolves down to file access permissions as well as read/write. You can't execute any type of data update stuff (you'll get "operation requires an updateable query") unless the user supplies credentials that allow them to write, or you allow write on the file.
Running a query requires only read access.