Open Exclusive Error Message Question? (1 Viewer)

I have an access app that is on a shared location on a network, but only want to allow a single user to open it at any time.

On each computer I have added the /excl switch to the shortcut so they get the message to say its open exclusively by another user, but they still get the option to open in shared mode and change data.

can I trap this message and use a custom message instead that will not allow it to open the database?

That defeats the purpose of using the network.

I can't see the purpose of this either but perhaps you could:
- use the shortcut to run a separate startup utility (another Access file or a batch file) which checks the network for the presence of the Access lockfile (.laccdb or .ldb) for your main Access app.

If the lockfile does not exist, the main Access app is then opened
If it does exist, a message appears to inform the user & then the startup utility is closed

HTH

you cannot stop the app from being opened, but once open it can check for the existence of a textfile called say 'AppExclusive.txt'. The file doesn't need to contain anything, but could contain say the users login ID so you know who has exclusivity.

If the file exists, the app is closed, if it doesn't then it creates the text file.

When the user closes the app, a bit of code then deletes the file.

It's not perfect - the user may suffer a powercut or close the app in a way that avoids running the delete file code (in which case you will need to delete the file manually). Or the user holds down the shift key to stop code running, Or first time use, the code is disabled and user may not enable it. And you will need to cater for the situation where two users try to open the app at the same time - the initial code run on opening still takes a bit of time run to and create the file.

It doesn't sound like you have set your file up correctly. The tables should be in a backend file located on your network. Everything else should be in a front end linked to the back end and a copy located on each users machine.

@Ridders - checks the network for the presence of the Access lockfile

If the file is opened exclusively, a lock file is not created

@Accessbug

If only one person is allowed to make changes you could include /ro in your commandline in addition to /excl for those who are not allowed to make changes

You may also want to check out the /cmd switch as well

https://support.office.com/en-us/article/Command-Function-fec67826-7fd7-48ed-a7aa-479c020ffaa4

Hi CJ.
You are of course right about the lockfile and thanks for mentioning it.

I meant to add that, if you use my approach, you no longer need to open the db in exclusive mode

This is, in general, a difficult problem if you really absolutely want to lock it down.

The reason is that because of session failure issues - like a "network drop" or a "system crash" or "application crash" or other "gotcha" situations, you will have the potential to screw up any indicators you try to build. That is, the problem will be not in doing something to lock your DB, but in UNDOING that lock when done. ANY session loss will have the same result - you "go away" before you get the chance to release your lock. Which means manual intervention will be required to unlock things.

You might do better to consider WHY you want only one writer at a time and see if there is another way to think about sharing your data. Exclusivity has a high cost. Sharing has a high cost - but is less difficult to manage than true exclusivity.

You would have to understand what the app does as to why its important no more than one user is using it. although other users can use it when it becomes available

AccessBug27 said:

You would have to understand what the app does as to why its important no more than one user is using it. although other users can use it when it becomes available

Click to expand...

So enlighten us? We can't guess what's the best solution for your issue, without you telling us the background.

I can understand that you have an issue, but my statement stands. True exclusivity that is somehow shared chronologically, just not simultaneously, still risks having a lockout due to any kind of session "whoops" event.

What is it that cannot be shared among simultaneous users and yet that CAN be shared enough for them to see the data, just not update it?