I have a table that defines everything I need to know about a pc that contains a copy of my front-end database. It contains the name of the pc, the name of the primary user, their telephone number and location, a "new version" flag that, when set, indicates that a new copy of the front-end database needs to be copied to the machine. It also contains a date/time stamp which indicates which version of the database is loaded on the machine, an "Exit Now" flag, and a "Broadcase Message" flag. I also store the name of the front-end database in this record because I could have more than one database (different projects) running on a user's machine. I store other info in this table also, but these are the main things.
At startup, a function is called to, first determine if the pc has been registered (i.e. pc's name exists in the table). If not, then a form is displayed that asks the user to enter the above info (the name of the pc is obtained programatically). If the pc has already been "registered", then it checks to see if the "new version" flag is set. If so, then the current version of the front-end database is deleted from the user's machine, a new version of the front-end is copied to the user's machine, and the "new version" flag is cleared.
I use a date/time stamp as my version number indicator and store the date/time as a custom property in the Database Properties. After I make changes to my database, and prior to releasing it to the users, I set this property to the current system date/time. After the new version is copied to the user's machine, I set the date/time field of the pc registration table equal to this custom property. This way I can look at the table to see which version of my database exists on each pc. (Note that the user will always run the most current version because it is automatically copied to the users' machine at startup.)
It may seem like a lot to set up, but if you create a library database (consisting of a front-end and back-end), you can use this method with every database you create. Simply store, in the front-end, the "registration form", the function that checks to see if the pc is registered, and the function that launches the code to copy a new version to the users' machine. Store the registration table in the back-end.
Also, by storing all of this information in a library database, you can continue to add stuff to your library and the registration table will come in handy for some of this "stuff". For example, suppose you want everyone to log out of your application. And suppose your program was able to kick everyone out but one. You can then determine who is logged into your application (based on user name) and join this with the registration table to determine their phone number and location. This is just one example of how the registration table can be very handy to have in supporting systems.
You could just have a table that contains just the "new version" flag. But it will only take you a couple more minutes to add the other fields to the table.
These are the things you will need to make this work.
1. Library database (front-end)
2. Library database (back-end)
3. Code to determine name of pc (can be found in this forum)
4. Code to copy new database to user's pc (can be found in this forum)