Problem with two instances of a FE open at same time?

[twgonder]

During my development, over the past two years of getting started with Access again, I’ve often found two instances of a .accdb running at the same time. I only find this by looking at the taskbar icon, and seeing two there. Often I can’t recall how this happened exactly, as there were often crashes while testing code. Because I’m developing on a non-split .accdb, I expect and have had various problems.



Anyways, I found I could do this on purpose, by just starting Access twice (not double clicking on a .accdb file) and choosing the same .accdb file. Some have reported that users have done this, and crashed the .accdb and contaminated data. Indeed, I’ve read that everyone should have their own local .accdb file and not use one found on a network drive. However, the posters that had corruption weren’t clear if the user that opened two instances of the same .accdb were using a split database or not. So, I’m a bit unclear if there could be a problem opening the same .accdb on the FE workstation if they are linked to a BE.
The potential problem I see is if deep in the workings of Access one open FE could contaminate the environment of the other running FE. We know from my previous posts that MS wasn’t careful to isolate workspaces as two forms with procedures calling a separate module procedure can stomp all over each other’s declared module variables.

The reason I understand that users would open two FE is if they are needing to view something different in the db (i.e. based on an incoming phone support call) and don’t want to close what they already have open. Instances of forms were supposed to take care of this, but as I showed in other postings, again MS didn’t do a good job with isolating and controlling multiple instances of workspace in this situation either, it’s full of bugs and improper code execution paths. On top of that, you might have to consider two different Windows accounts (users) could open the .accdb independently. Does each need their own .accdb and not use one FE from a common folder on the workstation?

So, is there a problem with two FEs open at the same time, on the same workstation, against one (or more) BE?

If so, I looked and didn’t find an elegant solution for testing if the .accdb is already open on the same workstation. There was one that suggested testing for the .lccdb, but that has limitations too. One has to consider that user A has the .accdb open, while user B in another Windows account might open the same FE .accdx file.

[Minty]

If users are sharing a PC, they should still have their own desktop and local Documents folders.
In my experience, you can open multiple individual copies of the same database on the same machine, provided each open version is separate copy of the FE.

You can then check for the lock file, as each copy would have to have a different file name or be in a different folder.

I have actually built a small "Launcher App" to accommodate this for a client, and it creates a second copy of the FE on initial load (DB_No2), checks for the lock file and opens the second copy if DB_No1 is already open.
It seems to function quite reliably so far.

[Bulzie]

I would not have them open 2 FE instances, update your program to allow for multiple forms or reports if they need to compare data. I use this in my vb exe app launcher to check if the program is open but sure there are other ways to do it:

Private Sub Form_Load()
On Error GoTo ErrTrap
AppActivate "Your Database Name"
Form1.Hide
MsgBox "Your Database Name System is already open.", vbSystemModal
Unload Form1
Set Form1 = Nothing
End

[ranman256]

EVERY user must have their own FE.
think of other methods to compare 2 users.

[twgonder]

@ Minty #2 As I look out to the future, I'm considering how to distribute the FE to user Windows workstations. It makes the most sense to place the FE file in a commonly named folder on a specific drive (like d:\Adbs\Fe).
Windows should be smart enough that each user (windows account) running their own copy of a FE should work. The problem becomes getting the common FE out to each user's folder. It would be nice, and save storage space, if all users could use the same FE in a shared folder, in a split environment, from the same directory that the current version gets distributed to. What I haven't been able to find is a definitive answer if one FE or multiple FEs are necessary in this situation of a split database. It's odd that for decades mini and mainframes allowed users execution of the same program files without cross-contamination, but that this seems to be an issue for Access.

So, your launcher app, is this an .accdx ( x = d or e) file that launches a copy of another .accdx file? This sounds interesting in that it could be a way to not only open multiple instances of the same .accdx file, but also as a way to organize which .accdx is opened in a service bureau environment such as for lawyers and accountants (all being table based) and then the launcher could pull the same .accdx from the shared path. So far, I've just used file shortcuts, but your approach might kill three birds with one stone, if indeed multiple copies of a FE are necessary.

[twgonder]

@ Bulzie, thanks for responding. Have you seen sepcific information from MS about not opening two instances of the same FE in the same Windows user account?
Asuming that one shouldn't, can you explain your vb exe app launcher a bit better?

[Gicu]

You might want to check my free launcher here: https://forestbyte.com/ms-access-uti...a-db-launcher/
Cheers,

[twgonder]

@ ranman256 # 4 Do you mean every Windows account user? Why? A well-designed run-time workspace should never contaminate the source or another user account. However, we know that forms are often contaminated during a crash. Bad MS, bad!
Has MS addressed this question somewhere in their documentation, that I haven't been able to find?

What about having two different BEs open at the same time? Two different FEs too? (Kinda obvious as the links to the BE table would get messed up, again, bad design MS, bad!)

How was this done for decades before MS Access? A user attached to the db that held the data (there could be one for each client like Ford or Chevrolet), and then ran the programs that sat in another db file. There might be other dbs for universal data like postal codes (all of these linked to in some manner depending on the particular master db application). The programs that the user called ran in sandboxed workspaces, the source was never corrupted. Why is everyone jumping through hoops to overcome this basic and very common situation? Why in Access do we need copies and more copies of a FE to operate in an enterprise environment?

What do you mean by "think of other methods to compare 2 users"?

(I'm not atacking your response, I just think the whole question seems a bit foolish in that it has to be asked. And worse that I can't find any MS documentation on the topic, since they seemed to have thought of splitting a data base for multiple use. Why not think about multiple use on the same workstation for one or more users and dbs?)

[twgonder]

@ Vlad #7. Thanks (as always), I'll give it a look over. Since you bothered to write a launcher, I'm guessing you had the same problem at some point in your applications development.

[twgonder]

@ Vlad #7 I just looked over the description for FBA DB Launcher. It looks like a tool for the distribution of the FE. Does it also handle starting up a second (or third) instance of a db FE? How about for service bureau environments (i.e. accountants) that need to launch more than one client BE, maybe with a different FE?

[ArviLaanemets]

As I understood, you and other users are working directly with non-split access database. This is OK when different users don't use the database at same time, but there may be problems when they do this. Starting from the lock-file, which is created when the user starts the program, being shared instead of dedicated to certain user, and ending with your database getting corrupted as worst case.

The proved practice for several users to work with database simultaneously is to split the database to back-end (tables, queries, etc.), and front-end (forms, reports, etc.), and every user having his/her own copy of front-end.

[twgonder]

@Arvil # 11 I work with both integrated (non-split) for development and split (for production work). The issue isn't about splitting. It's about how many FEs do we need when one Windows Account user needs to open again the same .accdb or needs to open another .accdb with a different data set for a different client. The same is true when there can be two users on the same workstation with a set of FEs open at the same time that may conflict.

[ArviLaanemets]

The issue isn't about splitting. It's about how many FEs do we need when one Windows Account user needs to open again the same .accdb

Do you mean the user opens the same DB second time? Honestly I have no clue what happens! Haven't never have any need for this! To be on safe side, the user could create a copy of FE with different name, and open it. Then the second instance will be essentially another user with exactly same username. All interactions between FE and BE on start are determined by themself, the user determines only, has he/she the access to DB or not.

... or needs to open another .accdb with a different data set for a different client.

Of-course for different BE's the user must have separate FE's

The same is true when there can be two users on the same workstation with a set of FEs open at the same time that may conflict.

Both users have his/her own frond-end. Where the front-end is placed (in user's profile on local computer, on user's profile on Terminal Server in user's LAN, or on Network Resource in user's Lan, the user has access), doesn't affect anything. The only limiting factor is, that the BE must be accessible for all users - the best place for it is Network Resource accessible to all users in same LAN where all users are logged in.

In case some users need the external access to database, then the best way for this is to have a Terminal Server in your LAN, the user has FE in his/her profile on TS, and starts the database from there.

[twgonder]

@ Arvil #13

Do you mean the user opens the same DB second time? Honestly I have no clue what happens! Haven't never have any need for this!

I'm guessing you've never trained or used the software you wrote in a production environment?
Imagine you are deep in filling out an Access form and you get a phone call that needs an answer from the same db and form you are currently working in. You can't tell the caller to wait while you make copies of the FE (even if your local file permissions allow for that) so that you can answer their questions.

...then the best way for this is to have a Terminal Server in your LAN, the user has FE in his/her profile on TS, and starts the database from there.

Can you explain that a bit more (or give a link)? I've used the Terminal app to attach to a remote workstation/server and the local machine just works like a remote keyboard and monitor. But once we get into the multi-user multi-db situation, then we need to solve it on the remote application "server" as well (unless this is what Terminal Server is supposed to handle), or users are using the same FE there too.

I'm working to keep the environment simple, so, I'm trying to work around having a bunch of MS servers to handle and create even more complexity.

[Welshgasman]

I'm guessing you've never trained or used the software you wrote in a production environment?
Imagine you are deep in filling out an Access form and you get a phone call that needs an answer from the same db and form you are currently working in. You can't tell the caller to wait while you make copies of the FE (even if your NW permissions allow for that) so that you can answer their questions.

Sounds like you have not either, if you have to open a second copy of the DB for that?

http://allenbrowne.com/ser-35.html

Also on the mainframe systems I used, you would have had to save the data on that form, and reuse with different data. You could not have multiple copies of a screen knocking around.