Front End Auto Updater and Group Policy (1 Viewer)

dkmoreland

Registered User.
Local time
Today, 08:46
Joined
Dec 6, 2017
Messages
129
I am trying to implement the Front End AutoUpdating Utility that has been so graciously made available by Bob Larson. I am trying to run it on a network with a fairly strict group policy. Every time the code gets to the point of running the batch file, it stops. The batch file is created and just sits there. When I try to run it manually, I get a group policy error.

I'm a contractor here so I have minimal access and authority. I asked the IT folks - they did open it up so this batch file will run if it is in the %TEMP% folder on the user's local drive.

So my question is - where do I modify the code below to accommodate this? I can see where the path to the Testfile is set but where does CurrentProject.Path come from?

Code:
Option Compare Database
' global variable for path to original database location
Public g_strFilePath As String
' global variable for path to database to copy from
Public g_strCopyLocation As String


Public Sub UpdateFrontEnd()
Dim strCmdBatch As String
Dim notNotebook As Object
Dim FSys As Object
Dim TestFile 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 = g_strFilePath
' sets the file name and location for the file to copy
strReplFile = g_strCopyLocation & "\" & CurrentProject.Name
' sets the file name of the batch file to create
TestFile = CurrentProject.Path & "\UpdateDbFE.cmd"
' sets the restart file name
strRestart = """" & strKillFile & """"
' creates the batch file
Open TestFile 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
'Exit Sub
' runs the batch file
Shell TestFile

'closes the current version and runs the batch file
DoCmd.Quit



End Sub

Or, do I need to modify this code (below) that actually makes the call to the function shown above?

Code:
Private Sub Form_Load()
Dim strFEMaster As String
Dim strFE As String
Dim strMasterLocation As String
Dim strFilePath As String

' looks up the version of the front-end as listed in the backend
strFEMaster = DLookup("fe_version_number", "tbl-version_fe_master")

' looks up the version of the front-end on the front-end
strFE = DLookup("fe_version_number", "tbl-fe_version")

' looks up the location of the front-end master file
strMasterLocation = DLookup("s_masterlocation", "tbl-version_master_location")

' checks for the existence of an updating batch file and deletes it if it exists
    strFilePath = CurrentProject.Path & "\UpdateDbFE.cmd"
    
    If Dir(strFilePath) <> "" Then
        Dim fs As Object
        Set fs = CreateObject("Scripting.FileSystemObject")
        fs.DeleteFile (strFilePath)
        Set fs = Nothing
    End If
        

' if the current database opened is the master then it bypasses the check.
If CurrentProject.Path = strMasterLocation Then

    Exit Sub
    
Else

' if the version numbers do not match and it is not the master that is opened,
' the database will do the update process
    If strFE <> strFEMaster Then
        MsgBox "Your program is not the latest version." & vbCrLf & _
        "The front-end needs to be updated.  The program will " & vbCrLf & _
        "now close and then should reopen automatically.", vbCritical, "VERSION NEEDS UPDATING"
        
        ' sets the global variable for the path/name of the current database
        g_strFilePath = CurrentProject.Path & "\" & CurrentProject.Name
        
        ' sets the global variable for the path/name of the database to copy
        g_strCopyLocation = strMasterLocation
        
        ' calls the UpdateFrontEnd module
        
        UpdateFrontEnd
        
    End If
    
End If

End Sub

Thanks in advance for any and all input.
 

Cronk

Registered User.
Local time
Tomorrow, 02:46
Joined
Jul 4, 2013
Messages
2,770
CurrentProject.Path is an Access system command which returns the path to the folder containing the accdb file in which the command is executed.

I'd put the Form_Load code in the first form that is opened. As I normally call an Autoexec function to do all preliminary checks when the database is opened, I put any version updating there.

Incidentally, because at some sites IT policy is to prevent batch files running, I do the updating from another Access db, called Updater.accdb. This is useful for easy installation of the front end for any new user.
 

dkmoreland

Registered User.
Local time
Today, 08:46
Joined
Dec 6, 2017
Messages
129
The Form_Load code is already in the opening form. The UpdateFrontEnd code is in a separate module and is called by the Form_Load code.

The question is how to make this code write the batch file and run it from %TEMP%. The group policy has been modified to allow the batch file to run from there.
 

isladogs

MVP / VIP
Local time
Today, 15:46
Joined
Jan 14, 2017
Messages
18,186
Incidentally, because at some sites IT policy is to prevent batch files running, I do the updating from another Access db, called Updater.accdb. This is useful for easy installation of the front end for any new user.

I do the same. See attached.
In my opinion, this also looks more professional than having a batch file DOS window displayed....
 

Attachments

  • ProgramUpdates.zip
    454.7 KB · Views: 218

dkmoreland

Registered User.
Local time
Today, 08:46
Joined
Dec 6, 2017
Messages
129
I was able to make it run successfully from my local drive - there is no batch file DOS window displayed.

I would be more than happy to use an updater db - I'm not married to the batch file idea. Can somebody point me to a working example?

Thanks.
 

RuralGuy

AWF VIP
Local time
Today, 09:46
Joined
Jul 2, 2005
Messages
13,826
You should be able to reference the %temp% value with this: environ("temp")
...so change this:
TestFile = CurrentProject.Path & "\UpdateDbFE.cmd"
...to...
TestFile = environ("temp") & "\UpdateDbFE.cmd"
...in the first set of code. It executes as the last part of that same code.
 

dkmoreland

Registered User.
Local time
Today, 08:46
Joined
Dec 6, 2017
Messages
129
You should be able to reference the %temp% value with this: environ("temp")
...so change this:
TestFile = CurrentProject.Path & "\UpdateDbFE.cmd"
...to...
TestFile = environ("temp") & "\UpdateDbFE.cmd"
...in the first set of code. It executes as the last part of that same code.

That's what I was looking for! I'll give it a try. Many thanks!

Quick update - that worked exactly how I needed it to. Thanks again.
 
Last edited:

isladogs

MVP / VIP
Local time
Today, 15:46
Joined
Jan 14, 2017
Messages
18,186
Glad you've got it working.
If you want to try using a separate updater.accdb file like that in the info I posted, let me know.
You would need to adapt it for your setup.
 

RuralGuy

AWF VIP
Local time
Today, 09:46
Joined
Jul 2, 2005
Messages
13,826
That's what I was looking for! I'll give it a try. Many thanks!

Quick update - that worked exactly how I needed it to. Thanks again.

You're most welcome. Glad we could be of help.
 

Mark_

Longboard on the internet
Local time
Today, 08:46
Joined
Sep 12, 2017
Messages
2,111
@OP,

While you may get the batch file to work now, I'd really look into the method the other's are proposing. It avoids many issues when user configuration is not what you expect. If the clients IT misses a machine for rights or variables (or if they put something odd on the network that they think works properly) a program that is far brighter than a batch file can be much better at explaining what went wrong. Also avoids having ONE end users not updated without you catching it.
 

dkmoreland

Registered User.
Local time
Today, 08:46
Joined
Dec 6, 2017
Messages
129
@OP,

While you may get the batch file to work now, I'd really look into the method the other's are proposing. It avoids many issues when user configuration is not what you expect. If the clients IT misses a machine for rights or variables (or if they put something odd on the network that they think works properly) a program that is far brighter than a batch file can be much better at explaining what went wrong. Also avoids having ONE end users not updated without you catching it.

Mark - I see your point and in fact, was thinking I might ought to check out the other method. Batch files can be wonky sometimes - as wonky as end users. :D

Colin - would you be willing to a share yours with me so I can check it out?

Thanks,
Diana
 

isladogs

MVP / VIP
Local time
Today, 15:46
Joined
Jan 14, 2017
Messages
18,186
Mark - I see your point and in fact, was thinking I might ought to check out the other method. Batch files can be wonky sometimes - as wonky as end users. :D

Colin - would you be willing to a share yours with me so I can check it out?

Thanks,
Diana

Please see attached for the updater utility together with instructions for its use

Hope you find it easy to use.
It should work any any version of Access from 2010 onwards, 32-bit & 64-bit Access are both fine.
@Gasman - please note that it may also be OK in Access 2007 ! :cool:

Let me know how you get on with this and whether the instructions need altering in any way.
Once I've heard back from you, I may place a copy in sample databases area for future convenience
 

Attachments

  • MDSUpdater.zip
    423.4 KB · Views: 273
Last edited:

Mark_

Longboard on the internet
Local time
Today, 08:46
Joined
Sep 12, 2017
Messages
2,111
Colin,

Something to consider as a future upgrade...
If you have a system with user information, have the "User" passed to the updater and keep a log of who updates when. Idea being, if you have 60 users of your software, you should be able to have a display that shows for each user what version they "SHOULD" be running currently. Likewise you can see if one user has updated more than once from a previous version (Using another's computer possibly, or has more than one copy for some reason) as well as those who haven't.

Just the pesky CDO side of me wanting to know who is being naughty.

Alternative may be to record computer names and use those instead.
 

isladogs

MVP / VIP
Local time
Today, 15:46
Joined
Jan 14, 2017
Messages
18,186
Hi mark

That's already in place.
I have a central log folder with a separate text file for each computer listing details of updates for each of my applications being used

In addition, user login details for each session including version number, workstation, login date time and logout date time are saved automatically in each program.

It's difficult for users to stop the updates running but if for any reason they continue to run an outdated version, that's logged automatically.

Oh and whilst I'm at it, I may as well mention that each feature they use is automatically logged as well. This allows a list of personalised 'favourites' to be listed n the user home page. It allows me to identify which features are used a lot a which not helping to inform priorities for future upgrades

Finally, if an error occurs, an email is automatically and 'silently' sent to me from the app giving details of who/what/where/when. As a result, I can make sure any bugs are dealt with quickly.
 

Users who are viewing this thread

Top Bottom