It sounds like you have a lot of databases to maintain and that some users may have more than one database on their machine. I have the same problem. What I describe below makes it real easy for me to maintain all of my databases. It is not as complicated as it may appear but will take a little time to develop (well worth it when it is done). What you can do is pick the pieces you need immediately and build them into you library database. You can then build the other pieces at your leisure.
As you can see, there are many ways that you can do what you want, but this works for me.
From my desk I can force users out of a given database, send a new copy or version of the FE db to one or more users, see who's logged in to a given database, and broadcast messages to one or more users.
In every database I create, the AutoExec macro calls a startup function who, in turn, calls a startup function in my library database. The reason I have a local startup function is because on rare occasions I have to do something specific for that database at startup.
1. I pass the name of a table to my library startup function so that I can determine which database it resides in. I can then determine whether my tables are linked to the "Live" database or a "Test" database (stored in a public variable).
Call Lib_StartUp ("tblName"
2. It then checks to see if I'm the CurrentUser. If I am the CurrentUser, it then checks to see if the database (project) has been registered. If not, it pops up a form which forces me to define/document the project. This is some of the information I collect (you can add or delete what you want).
1. Project name/title
2. Name of the FE database
3. Name of the BE database
4. Name of the Workgroup file that is used by this db
5. Name of the share where the Master copy of the FE database resides
6. Name of the share where the Live version of the BE database resides
7. Name of the folder where the FE db resides on the user's machine
8. Name of the share where the workgroup file resides
9. Name/phone number of primary and secondary support personnel
10. Comments to describe the purpose, etc of the database
11. Latest revision date
With this information you can do a number of things. For example, when you need to copy a new version to the users' machine, you know where to copy from (5) and where to copy to (7). Also, if you're on vacation and someone else is supporting your databases, they may not know how to startup your database (i.e. what workgroups to use, etc). Consequently, you could have a form with a combobox that lists all of your databases (1) and when they select one, it opens the databases like this: \path\msaccess.exe Item5Above\Item2Above /wrkgrp Item8Above\Item4Above.
3. It then checks to see if the pc has been registered. If not, it pops up a form which forces me to define the computer. This is some of the information I collect (you can add or delete what you want)
1. Name of the pc (environ("computername"
)
2. Name of the primary user/owner of the pc
3. Phone number of primary user
4. Location of the pc (office number,etc)
5. Shutdown flag (if set, db immediately shuts down and new users are not allowed to login)
6. New Version flag (if set, a new version of the database is copied to the user's machine. Note the project table above will let you know where to copy from and copy to.)
7. Broadcast Message flag (if set, a message from the administrator (you) is displayed on the user's machine)
8. Reregister computer flag (pop this form up at startup. Sometimes when I install a database on a user's machine, they are not there so I can't get their phone number, etc. This allows me to get it at a later date.)
4. It then checks to see if the user has been registered. If not, it pops up a form which forces me to register the user. This is some of the information I collect (you can add or delete what you want)
1. Name of the user
2. phone number
3. Location
4. Name of form they want opened at startup (some users always go directly to the main edit form, others go directly to the report criteria form. This allows the user to specify which form they want to go to at startup) (A shortcut can also be put on their desktop, but this works better for me)
5. If then checks to see if a new version of the database (NewVersionFlag is set) needs to be copied down to the user's machine (This relates to your original question). If it does, then (instead of using a batch job), I launch my library database, like this:
strAppName = SysCmd(acSysCmdAccessDir) & "MSACCESS.EXE" & " " & CodeDb.Name & " /user " & gstrLibUser & " /pwd " & gstrLibPwd & " /wrkgrp " & gstrLibWrkGrp
strCommand = " /x MyAutoExec /NoStartup/Cmd " & _
"NewVersionFileCopy" & ";" & _
strComputerName & ";" & _
strCopyFrom & ";" & _
strCopyTo & ";"
Call Shell(strAppName & strCommand, vbNormalFocus) '1 Library is launched and the function NewVersionFileCopy is executed via the macro MyAutoExec
Application.Quit 'Current FE exits (library db open now)
Note that gstrLibuser, gstrLibPwd and gstrLibWrkGrp are public variables. The first 2 are constants and the third one has been read from my project library. You can also get it via a system command (forget offhand)
At this point your database has exited and the library database is opened. Now the function NewVersionFileCopy simply copies a new version to the user's machine and then launches the user's FE db and the library db exits. Prior to exiting, the NewVersion flag will need to be cleared.
Note that NewVersionFileCopy knows where it is to copy it from and to based on the command line arguments used to launch the library database.
