Solved Can I copy a front end and rename it for someone else to use? (1 Viewer)

User6598

New member
Local time
Tomorrow, 06:17
Joined
Sep 12, 2021
Messages
3
I would like to say that I am not an Access developer by any means and I have been asked to help out with an issue with a project.
One of my team member's Front end(FE) is corrupted for some reason, when looking at their VBA, there is no code in there.
Other users' FEs are working fine and they have all modules and code in VBA.

I want to know if I can delete the corrupted FE and copy a FE of another user whose code and form and modules are working. Rename that FE and give to the other user to use?

As a test I copied someone's front end into another folder, renamed it and opened it. I can see all the code and modules in it. However is it a good idea ? Is that how Front ends are distributed? Once split how does one make copies of Front ends for many users? Is it as simple as copy and paste multiple copies of the split up Front end?
 

CJ_London

Super Moderator
Staff member
Local time
Today, 19:17
Joined
Feb 19, 2013
Messages
16,553
I want to know if I can delete the corrupted FE and copy a FE of another user whose code and form and modules are working.
yes you can in principle. Depends on what you mean by rename, but renaming shouldn't be required, just replace the corrupted version with the uncorrupted one.

If by renaming you are saying all the FE's are on the server and each named for a specific user, then that is not the way FE's are distributed. Each user should have a copy of the FE on on their local machine (all with the same name).

With regards 'in principle', the other consideration is if the the FE contains tables that are populated with data specific to the user which needs to be retained, then you will need to copy those tables from the corrupted FE to replace those in the newly copied replacement FE. Generally speaking FE's should contain no tables at all - instead they should be created in another local backend.

As for the corruption - Access should not be used in a wireless environment. Doing so will lead to corruption of the FE and potentially the BE as well.

There is plenty of advice on this and other forums as to how to distribute FE's and set up for a network.
 

User6598

New member
Local time
Tomorrow, 06:17
Joined
Sep 12, 2021
Messages
3
yes you can in principle. Depends on what you mean by rename, but renaming shouldn't be required, just replace the corrupted version with the uncorrupted one.

If by renaming you are saying all the FE's are on the server and each named for a specific user, then that is not the way FE's are distributed. Each user should have a copy of the FE on on their local machine (all with the same name).

With regards 'in principle', the other consideration is if the the FE contains tables that are populated with data specific to the user which needs to be retained, then you will need to copy those tables from the corrupted FE to replace those in the newly copied replacement FE. Generally speaking FE's should contain no tables at all - instead they should be created in another local backend.

As for the corruption - Access should not be used in a wireless environment. Doing so will lead to corruption of the FE and potentially the BE as well.

There is plenty of advice on this and other forums as to how to distribute FE's and set up for a network.
This is interesting and very useful information. The developer who built this tool has left the company a while back. I can confirm that the FEs are all in one place on a server with individual names assigned to FEs so they only access their own FE. Also I can confirm that there are no tables in FEs, all tables are in a backend and all FEs are pointing to the same BE. Thank you for the insight, I will do some more checks to see if there is anything user specific (I have not seen anything yet) but if so then I will need to do some fixing.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 12:17
Joined
Oct 29, 2018
Messages
21,358
Hi. The main thing to remember is to make sure each user is using a separate front end. If that means naming the file to indicate who is supposed to use it, then that is acceptable. It could also mean keeping the same file name but storing the user copies in separate network folders. But, as already mentioned, the preferred method is to use a copy of the front end on each user's local machine.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 15:17
Joined
Feb 19, 2002
Messages
42,972
To summarize. Each user needs a personal copy of the FE. This will normally be loaded on his PC rather than on a network drive. The BE is shared by all users and is on a network drive. There are several methods of distributing new copies of the FE. It would appear that the original developer didn't know how to do that and so settled on putting all the FE's on the Server. This is not optimal for performance or distributing new copies of the FE but is otherwise OK.

I use a shortcut on each user's desktop. The shortcut runs a batch file (located on the server so that it can easily be updated if necessary). The batch file creates the necessary directory on the User's PC, copies the current master version of the FE to the local drive and then opens it.

Code:
md c:\DwgLog
del c:\DwgLog\DrawingLog.accdb
copy "\\BSCCTIMBERLINE1\Timberline Office\AccessApps\Data\CommonFE\DrawingLog.accdb" c:\DwgLog
c:\DwgLog\DrawingLog.accdb

The .bat file has no error checking because errors can be safely ignored except for the "copy" and the user will know he has no FE and report the problem.
 
Last edited:

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 14:17
Joined
Feb 28, 2001
Messages
26,999
I'm going to offer an explanation of WHY it is not optimal to have each user with a private copy of the FE that resides on a server (vs. each person having a local copy of the FE on their local machines.)

Window has this thing that you cannot turn off. It is called "File Locking." It is there to prevent users from "stepping on each other" when they work in a shared area. This makes it a good thing. Good if sometimes pesky. Sometimes, Windows determines that a lock collision is about to occur and will prevent one user from overwriting another user's information. It is possible for Windows to just momentarily delay a write-back or it can give you a nastier "File Locked" message. That occurs in what is called a "collision."

In general, the locks on a file are managed by the machine on which that file resides. So for the shared BE file that everyone uses, the server manages the file locking for access requests coming in over the network. However, the FE file has its own set of locks EVEN IF NOT SHARED. (Like I said, it is hard to turn off file locking.) Here is the crucial part: If the FE file is local then the locks are managed at local memory speeds and the file permission information that drives the locking occurs based on local-disk speeds. If the FE is networked, then the locks are managed at network speeds and the file information occurs based on network-shared disk speeds.

There is another catch... folders are files, too. The BE file has to be shared and so does its folder. The folder's locks are also (separately) managed by the server. BUT if you have a shared folder where all of the individualized FE files were kept, the folder locks are ALSO shared over the network. If you put the files in a local folder on the user's machine, the folder's locks are locally managed. There can be NO lock collisions for FE files if they are local to each user because no one else will even try to touch them. Therefore the only collisions will be for the BE file and folder. Since Access is designed to minimize its network "touch" strategy, spreading the FE files to local machines minimizes lock collisions. Which is a good thing.

The last part of this that needs explaining is, why is network management so bad? Really, it is technically OK and Windows manages locks all of the time ... but there is a speed issue. The data for file locks, when managed locally, is probably available within a few microseconds (on a 2.5 GHz machine) whereas network connections are more often a few hundred microseconds for a fast network verging towards ten milliseconds for a slower network. Can Windows run OK in this slow networked environment? Yes, easily. Easily - but not quickly. If you have everything networked to the hilt, will it break your app? Probably not, unless the network is flakey. But it will make your app slower than it really needs to be and really COULD be.

In the real world, smaller offices usually DO NOT have Gigabit Ethernet, so the more widely you distribute your files across your intranet, the slower things are going to run.
 

Users who are viewing this thread

Top Bottom