I thought I'd share some tips on publishing an Access application for those who are new to the concept.
1. Separate your front and back ends.
http://hitechcoach.com/index.php?option=com_content&view=article&id=35:split-your-access-database-into-application-anddata&catid=65:split-database
2. Ensure each user has a copy of the front end. Not a shortcut to it. This avoids problems where users may be editing the same record at the same time as well as a host of other issues caused by multiple users being in the same MDB at the same time.
The problem with this is that now when you make a change to the front end, you or your users need to update the file version they are using.
The solution to this problem is to give the user a front-front end which makes a per-user copy of the real front end and launches that using the OpenCurrentDatabase method:
http://msdn.microsoft.com/en-us/library/aa221388(v=office.11).aspx
You can simply generate a random number/hash to append to the file name to ensure that two different users aren't using the same copy, but I like to append the environment's username variable.
I feel this solution is more elegant than the one in which the user's application checks its version number against a global version number and overwrites itself in the case where they aren't equal. It is no more space efficient (in both cases there is a copy of the front end for each user using it) But it doesn't rely on anything (table links, file/folder paths, etc.) other than a shortcut to a front-front end.
1. Separate your front and back ends.
http://hitechcoach.com/index.php?option=com_content&view=article&id=35:split-your-access-database-into-application-anddata&catid=65:split-database
2. Ensure each user has a copy of the front end. Not a shortcut to it. This avoids problems where users may be editing the same record at the same time as well as a host of other issues caused by multiple users being in the same MDB at the same time.
The problem with this is that now when you make a change to the front end, you or your users need to update the file version they are using.
The solution to this problem is to give the user a front-front end which makes a per-user copy of the real front end and launches that using the OpenCurrentDatabase method:
http://msdn.microsoft.com/en-us/library/aa221388(v=office.11).aspx
You can simply generate a random number/hash to append to the file name to ensure that two different users aren't using the same copy, but I like to append the environment's username variable.
Code:
UCase(Environ("USERNAME"))I feel this solution is more elegant than the one in which the user's application checks its version number against a global version number and overwrites itself in the case where they aren't equal. It is no more space efficient (in both cases there is a copy of the front end for each user using it) But it doesn't rely on anything (table links, file/folder paths, etc.) other than a shortcut to a front-front end.
Last edited:
