Close access before updating the FE

[Perceptus]

Any suggestions for closing Access remotely on PC's before updating the FE on those PC's? I was thinking maybe use 'taskkill' to close the items remotely via batch file.

[JamesDeckert]

What do you mean by, "before updating the FE"?
If your data is in the BE, what are you preventing?

[Perceptus]

Well, When it comes time to push the next FE Update to PC's users are usually not at their Stations. I would want to close the FE on their PC. and then Update the FE.

I would be preventing the copying of a FE to a users pc while they have that front end open. Doesnt seem smart at all to update a file that someone has open.

[June7]

My procedure is to update the frontend when user opens it. I have a master copy of frontend on which I do modifications. When ready to deploy, I change the version number in a table and the version number in a label caption on a form set to open by default. Then I copy the db into another folder named Install. User opens their copy of db on their computer and because the label caption no longer matches the version number in table, code will copy the db from the Install folder, close and reopen the db which is now the new version. Review http://forums.aspfree.com/microsoft-...ue-323364.html

At this stage of my db's life, most edits I do would not impact users who already have db open. So the next time they open they will get the latest.

[Perceptus]

June7,
Reading the code in your link. My concerns from old windows issues where trying to overwrite an existing file that is open errors out. Is this not an issue you have to deal with using your solution?

[June7]

Nope. I don't really understand why it works (found code) but it does and has for years.

[Perceptus]

LoL. Well thats a good enough reason for me to try it out. Thanks June7

[June7]

It's not perfect. I have one computer the user has to reboot after the file is copied or some forms in the db won't work properly - calcs in textboxes won't work and stay blank. He restarts and everything back to normal. Very weird and no idea why. But this computer has been weird in other ways ever since we got it.

[ItsMe]

Before I started to automate the process of updating FE files, I read one of June7's posts about it. It got me thinking that I should have the process automated, too. In the end, I decided to go with an external batch file. In the file, I put a two second pause to allow the Access file to close. Two seconds has worked well for me. This gives enough time for the Client machine to create a new batch file and shut itself down, before the batch file tries to delete and replace the Access FE file.

Each client is stored on the local C drive. When the User launches their file, it runs from the C drive and checks a table on the BE to determine what the latest FE version number is. The master FE file is stored on a server share.

When I develop a new version of the FE, I create a copy and place it into the share on the server, replacing the outdated master copy. Then, I append a record to the FE versions table within the BE . Then, I email blast the users, letting them know an update is available and instructing them to close their FE files.

To start with, you need a procedure in a standard module or behind your startup form.

Public Sub UpdateFrontEnd(strFilePath As String, strCopyPath As String)

Dim strScriptFile As String
Dim strKillFile As String
Dim strReplFile As String
Dim strRestart As String

' sets the file name and location for the file to delete
strKillFile = strFilePath

' sets the file name and location for the file to copy
strReplFile = strCopyPath

' sets the file name of the batch file to create
strScriptFile = CurrentProject.Path & "\UpdateDbFE.cmd"

'see if this cmd file already exists
    If Dir(strScriptFile, vbDirectory) <> "" Then 'Kill the file
        Kill strScriptFile
    End If

' sets the restart file name
strRestart = """" & strKillFile & """"

' creates the batch file
Open strScriptFile For Output As #1
Print #1, "Echo Off"
Print #1, "ECHO Deleting old file"
Print #1, ""
Print #1, "ping 1.1.1.1 -n 1 -w 2000"
Print #1, ""
Print #1, "Del """ & strKillFile & """"
Print #1, ""
Print #1, "ECHO Copying new file"
Print #1, "Copy /Y """ & strReplFile & """ """ & strKillFile & """"
Print #1, ""
Print #1, "CLICK ANY KEY TO RESTART THE ACCESS PROGRAM"
Print #1, "START /I " & """MSAccess.exe"" " & strRestart
Close #1

'Runs the batch file
Shell strScriptFile
DoCmd.Quit

End Sub

If the app determines it needs to update itself, it calls the procedure like this ...

MsgBox "There is a newer version of this application available." & vbCrLf & _
       "Please standby while your version is shutdown and updated." & vbCrLf & _
       "The new version will open automaticaly.", vbInformation, "Update Necessary"
       
Call UpdateFrontEnd(CurrentProject.Path & "\" & CurrentProject.Name, "\\Server\Folder\" & CurrentProject.Name)

[June7]

What do you mean by 'create a new batch file'? Why does batch file need to be recreated? You don't have the bat file just sitting on user computer? Interesting. I had originally used a bat file then changed to the internal procedure. I still have bat file on each user machine which allows them to 'force' update.

[ItsMe]

What do you mean by 'create a new batch file'? Why does batch file need to be recreated?

I use an external script. The Access FE will create a script file. There may be one there already or there may not be one there. To keep the spirit of 'automation', I chose to have the FE manage the whole thing.

Each time an update is managed by the FE, a new script file is created. The first time an FE updates itself, there will not be a script file to run.

[ItsMe]

...You don't have the bat file just sitting on user computer? Interesting. I had originally used a bat file then changed to the internal procedure. I still have bat file on each user machine which allows them to 'force' update.

It seems you edited your post after I answered your original question.

As I mentioned in post #11, I do it this way in an effort to keep things automated. The FE knows its own path. The FE knows its own name. Doing it this way allows the procedure to work with any file and the only thing hardcoded is the path to the Master FE on the server share. Doing it this way, there is no need to distribute a script or a user to manually update.

[June7]

Yep, edited.

The internal procedure accomplishes all that without building bat file. Bat file is not needed and users don't have to manually update. But I have seen the copied file get corrupted and the automatic update will not work. So the bat file is there as a backup method to 'force' the update.

[HiTechCoach]

I find this FRONT-END AUTO-UPDATE ENABLING TOOL (Click Here) to be one of the best methods.