Keep users from opening multiple instances of access front end

[dcdimon]

I'm looking for any ideas on how to keep users from opening another instance of a front end file. I've seen some vb script out there, but I'm unsure of how to use it or what it's doing. So I'm hoping someone here can clarify for me.



Here's the issue we're working on solving:

There is a single front end file stored in the SHARED directory on a tablet. Every user has access to a shortcut on the desktop to this shared file.

On occasion we have a user that forgets to log out before the next user logs on. This puts the tablet into the situation where an instance of the front end is up and running under the last user, but the current user sees nothing. They then click on the shortcut and start up the database - while another is still running in the background.

We are having some issues where I think the background instance is autosaving records while the foreground instance is as well, creating duplicate records for that time frame.

What I'm looking for is something that will allow the front end to see if another instance is running and do something other than just start up another front end instance. For example I'd like to force a reboot of the computer to log off all users and set up a clean log in for the current user.

Or it can just warn them another instance is running and they can reboot manually.

The idea is to make sure we've only got one user and one instance of the front end working at a time.

Any ideas? Or are we trying too hard to program around operator error?

Thanks,
DCDimon

[June7]

One computer with multiple users, yikes. Users should not all be opening the same file. Each user should run their own copy of frontend, perhaps installed in their user folder. This means each user should have their own shortcut associated with their login profile.

Opens up another conundrum, how to keep all these copies updated with new version. I have code that automatically copies new version down to user computers. However, I discovered that file permissions do not permit this programmatic copy to occur into user folders so we have the frontend sit at the C: root on each computer. Also, we assume one user for each computer.

Or maybe instead of shortcut to db, shortcut to a VBScript that makes sure there are no instances of Access running. Either kills them or notifies user.

[dcdimon]

One computer with multiple users, yikes. Users should not all be opening the same file. Each user should run their own copy of frontend, perhaps installed in their user folder. This means each user should have their own shortcut associated with their login profile.

Opens up another conundrum, how to keep all these copies updated with new version. I have code that automatically copies new version down to user computers. However, I discovered that file permissions do not permit this programmatic copy to occur into user folders so we have the frontend sit at the C: root on each computer. Also, we assume one user for each computer.

Or maybe instead of shortcut to db, shortcut to a VBScript that makes sure there are no instances of Access running. Either kills them or notifies user.

We have multiple users because of 3 shifts in our facility. The tablets are specific to the work area, not the employee. We have a script and some internal vba/tables/queries that can see when there's a new version number available and it auto updates by exiting out of access, pulling down a networked copy of the file to the C:/Shared directory and then restarting the program. The short cut may be on each users desktop, as opposed to the shared desktop, but there is only one copy of the file to run.

A shortcut to VBScript would work as well as an internal Access script. However, I'm not sure how to institute either option.

I've seen something in VB using app.previnstance, but I'm not sure how to use it. Or how to program it.

DD

[June7]

As I said, shortcut would execute script file that would kill any instance of Access running and then open another instance of the frontend. This is assuming script executed by one user can kill app opened by another user - something I've never tried.

[dcdimon]

As I said, shortcut would execute script file that would kill any instance of Access running and then open another instance of the frontend. This is assuming script executed by one user can kill app opened by another user - something I've never tried.

That's one question I have as well. I haven't found a definitive answer about whether I can close something someone else opened. Another thought I had was if it sees another instance running it just reboots the computer. That would close everyone out and set up a clean user login.

[Missinglinq]

...but there is only one copy of the file to run..

Just to continus what June7 has said, having multiple users sharing a single Front End, on a network drive, is the sure way to repeated episodes of corruption, speed and timing problems, and all manner of strange, odd and curious behavior!

Being in forced retirement, I spend 8-10 hours a day here and on other Access forums/newsgroups, and over the past ten years have seen literally dozens and dozens of reports of split databases, using links to a single Front End, causing these kinds of problems, as well as massive data loss! The really insidious thing is that this kind of setup can work for extended periods of time before the troubles begin! But once it does, they become chronic, which is to say they occur over and over and over again!

You simply have to given each user their own copy!

Linq ;0)>

[dcdimon]

Just to continus what June7 has said, having multiple users sharing a single Front End, on a network drive, is the sure way to repeated episodes of corruption, speed and timing problems, and all manner of strange, odd and curious behavior!

Being in forced retirement, I spend 8-10 hours a day here and on other Access forums/newsgroups, and over the past ten years have seen literally dozens and dozens of reports of split databases, using links to a single Front End, causing these kinds of problems, as well as massive data loss! The really insidious thing is that this kind of setup can work for extended periods of time before the troubles begin! But once it does, they become chronic, which is to say they occur over and over and over again!

You simply have to given each user their own copy!

Linq ;0)>

Just to clarify - there is only a single front end on each tablet. It's in the c:\shared directory of the tablets. We aren't running off a networked file - that's only how we update out to the users. We have a script inside the database that's compares the version number of the local copy (in a table) and that of the network copy. If it's different then it auto updates. That's the only time the tablets look to the networked file.

We thought about putting the updated file in each users directory, however we decided that having that many files to manage as we update would put us in a unwanted position. We'd have tablets/users running multiple versions of the software because we can't guarantee that the update gets out to all users at the same time because of shift and staffing differentials. Having to wrangle 27 tablets is difficult enough, we didn't want to multiply by that 3 or more.

99% of the time users log off before turning in the tablet for the next shift. In those cases then we only have the current user running the front end. The problem is the other 1% that don't log off and still have Access open in their user evironment. Then we end up with the last user with the front end open - but no data being entered because it's running in the background - and the current user with an open and active front end. That is what we're looking to avoid. And, truthfully, the percentage is small enough we can deal with it as it occurs, we're just interested in automating it if we can.

We are currently experimenting with a VB script to test for an instance before it opens another and if it finds one it reboots the computer, forcing the last user off the tablet.

DD