User Lock out & Updating the DB Front End (1 Viewer)

[AJordan]

Developed with Access 2007, all computers running Vista

Question #1
I know I've seen this question on this board but I cannot find it. I have a properly split database. The back end is located in a shared public folder, which is mapped to each computer. They are all connect via 10/100 ethernet switch. Each computer is running a packaged version of the database and using runtime (only 1 computer has Access). Everything works correctly EXCEPT 1 (cpu #3) of the 4 computers, cannot access reports or forms bound to tables if other users are in them first. If cpu 3 goes in first everything is fine. No other computer has this issue, any thoughts on why this is even happening?

Question #2

I was running a test to see if I could update the front end to add upgrades or add a new feature to the current DB FE. I change the FE on the main computer (the one with Access), re-packaged the db. I proceed to email the new front end to the other user and they go to install. After they install and open the link to the DB, there are no changes. The FE has remained the same.

If the user uninstalls their front end db (via add/remove programs) and then installs the new FE everthying is fine. Is there a way around the hassle of having to unistall a packaged FE just to update it?

 

[Atomic Shrimp]

Is the installer placing the FE on the local hard drive, or in some shared network location? (reason for asking: is it possible that despite separate install processes, they're all running the same copy of the front end?)

 

[AJordan]

Yes, the front end is set to install onto the local hard drive on setup, so each person has their own copy of the FE.

I wish your question was the case, then I could have just slapped myself!

 

[Fifty2One]

AN alternate way is to have a common folder on the network for individual copies of the front end such as App1Shipping; App1Warehouse; App1FrontOffice; App1Receptionist. These are merely copies of App1 renamed for the individual workstations. This will prevent trouble of people hogging the app, too many people on a single app at one time and if someone has finger trouble or accidently trashes a copy it is not the common copy but merely one copy.

 

[boblarson]

AN alternate way is to have a common folder on the network for individual copies of the front end such as App1Shipping; App1Warehouse; App1FrontOffice; App1Receptionist. These are merely copies of App1 renamed for the individual workstations. This will prevent trouble of people hogging the app, too many people on a single app at one time and if someone has finger trouble or accidently trashes a copy it is not the common copy but merely one copy.

This is not a good solution though in that if you start an Access app from a network location you

1. bog down the network as it has to copy everything over to the workstation.

2. raises the risk factor greatly that the frontend will corrupt. Running any Access app from a network location runs a much higher risk of corruption than if you run it from the users machine.


AJordan:
Also, is this on YOUR network or a customer's? If on your network then what is the purpose of "installing" anything? You should be able to just copy the frontend to the local machine and run it (if they have Access or the runtime installed). Then you can use an auto updater, like the one mentioned in my signature, to manage the frontends.

 

[AJordan]

I am using my network to test before I deliver to my customer. Although this is happening on only 1 of my 4 machines, I don't want this problem to creep up again on my clients network without me having an explanation.

Currently the data is being stored on the "main" computer in a "public drive" folder. Tonight I'm looking to see if I move the backend to a Networked storage device will I have the same issue.

Also on cpu's 2-4 they are running the .accdr front end, while cpu one runs the bassic .accdb front end. When the client gets the database they all will use .accdr front end format as well.