Question about Access on a server (1 Viewer)

itmasterw

Registered User.
Local time
Today, 06:52
Joined
Oct 31, 2005
Messages
45
Hi,
I am a contractor, that was brought in to make some enhancements and upgrade their application from Access 2003 to 2010 and put it on a sever.
Now I know the first thing that you will say here is that they need to spilt it in a front end and back end and it is what I would do to; but they absolutely do not want to do that.
Anyway, I finished everything and put it on the 2008 R2 windows server and it works great. The next step though will be to have a few users use it, at the same time, to see if that works. I have not done a lot of Access applications on a server, most of mine was local to the user. And the few I did we split the database; but again they do not want to do that.

So, my question is what issues can I expect if any and how might I rectify them.

Thank you
 

kevlray

Registered User.
Local time
Today, 03:52
Joined
Apr 5, 2010
Messages
1,046
I not one of the experts, but my experience has shown if you have any number of users using the same database at the same time, your database will get corrupted. I realize the worst situation I saw was a bit different. But we had 20+ users using the same database (not split) on a shared Novell drive. There database was getting corrupted about every two weeks (fortunately we had a good backup system). Now every user has their own FE and the tables are on a MS-SQL database. No corruption or crashing issues.
 

sneuberg

AWF VIP
Local time
Today, 03:52
Joined
Oct 17, 2014
Messages
3,506
In this web page Microsoft says if you can do that if

  • No more than a few people are expected to use the database at the same time.
  • No Memo fields are present in the database, or if they are, they will not be simultaneously updated by different users.
  • Users do not need to customize the design of the database.
But I bet that some of the forum members are going to tell you that this set up will guarantee a corrupt database. Just in case they are right I suggest doing very frequent backups of this database, keeping multiple backups.

Another thing you might try is to have a table that holds the current number of users and if it exceeds a few then present them with a message that there are too many users and that they will have to try later.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 05:52
Joined
Feb 28, 2001
Messages
27,395
If they share a single-file Access database, expect frequent locking, program abort, and "unrecognized format" errors caused by that configuration. (Discussion below.)

You can show the persons making those decisions this post if you like...

They might not listen to you, but what IDIOT would ignore the advice of multiple seasoned professionals to SPLIT the database into Front End/Back End parts and to distribute the FE parts? The "single unsplit database" configuration is GUARANTEED to not work long-term. It WILL run into lock contention that will corrupt the database files and if you are not lucky, can PERMANENTLY corrupt the data tables. If that happens, the cost becomes the extra labor required to go back to the last good backup and to then try to get everyone to re-enter everything that happened since that restore point.

I was a contractor for the U.S. Navy for 28 1/2 years, the last several years being in a Navy Enterprise Data Center serving the entire Eastern Seaboard and some interior states. We had heavy security on the network including firewalls, multi-factor authentication, and other Dept. of Defense security methodologies in place. I had an elevated clearance and was certified for cyber-security issues to be a systems administrator on a machine covered by Privacy Act and HIPAA requirements. I was a first-line security admin and my work was reviewed by second-line security managers. They very rarely asked me anything because my systems were CLEAN.

I know about security requirements. I know about network load issues. If you are going to use a database in Access and don't want it to fail, you NEED a split database and you need the FE copies to be distributed among the users. Otherwise, locking conflicts will eat you alive and negate the usefulness of the database.

As to working on a 2008 R2 server, yes, it should work great with a single user. The ONLY way you are going to get it to work multi-user involves licensing issues. EITHER you need to have a proper multi-user license for Office on the server OR you need individual seat licenses to have individual FE files.

If the issue is money, OK, I understand. But you can throw the cost of technical support salaries for hours of hard and frequent database maintenance at the problem or you can simplify the problem by making a one-time purchase of Access (or Office) licenses for each user. Doing so will minimize the locking problem.

The mechanism of this problem is that if you open the BE file for shared use from each FE file, and if your FE has been set up for optimistic locking, the window of opportunity for lock collision is minimized. If each user has their own private FE file, the opportunity for query, form, report, and module collisions is totally eliminated because those locks will all be PRIVATE, not shared.

The problem may well be that the money wonks want to go "on the cheap" but Microsoft solutions are SPECIFICALLY DESIGNED to not allow that. That is why you technically need the right kind or number of licenses. Let us say that if you EVER had to ask for support from Microsoft and they found improper sharing, they DO pursue piracy - because that is what it would represent. I was able to avoid that with the D.o.D. due to the #1 rule that I could NEVER violate a license even if directly instructed to do so by a supervisor. My defense would always be that doing so was illegal and I required that order in writing with signatures, dates, and dated witness signatures.

IF the problem is IT types who don't like what SMB does to a network, OK, that is a legit concern - to be counteracted by (a) the multi-user license and (b) allowing each user to RDP in and have a private profile into which you can drop the individual FE files and have the single shared BE file visible to all such profiles. By having individual profiles with enough quota to hold private FE files, you can get the lock privacy in the FE file and the optimistic locking selection to still function as needed.

In any context, it would be OK to use local or domain group identifiers as the "permission vehicles" to allow folks to see what they each need to see. Your security people, assuming they have been trained in typical Microsoft "best practices," would want a way to use Access Control Lists to protect the relevant shared folder, and using local or domain group identifiers is the ideal way to go on that.

Itmasterw: Please note that I have couched this in a stern format but it is not directed at you. I understand having to beat management over the head with their own reluctance to make a decision. In a Dept. of Defense office? You had better believe that nobody wanted to make a decision that would earn them scrutiny. But you also have to learn that sometimes policy and money MUST take second place to technical issues. If you want a project to fail, just keep the tech folks from doing what is needed to make it work.
 

itmasterw

Registered User.
Local time
Today, 06:52
Joined
Oct 31, 2005
Messages
45
Thanks everyone for your post, it has been really helpful.

Thank you
 

gemma-the-husky

Super Moderator
Staff member
Local time
Today, 11:52
Joined
Sep 12, 2006
Messages
15,729
Out of interest, if anywhere in your database you store temporary information in a table, then you will have issues if multiple users do the same process. There is only one common table, and each users temporary information will overwrite each other's, often giving unexpected results later on.

This is another reason why we recommend that each user has their own dedicated front end.
 

Users who are viewing this thread

Top Bottom