Batch file for updating local frontend Access database copy

But if neither of them is on the client yet, then no.
A script or an exe file can specifically address this case.

But okay, it all depends on the environment you find at your customers' premises.
You mean, use an Access deployment tool, like Inno or SSE, to create an exe installer?

We created our own utilities library, that includes an Access deployment tool, by compiling vb.net programs. None of our users tinker with the hidden batch scripts. If they were to deviate from protocol and break something, they would pay dearly for us to fix it. We once had a creative user who changed the system date on his workstation to enter back dated transactions. That ex_user is no longer around 🙂
 
Last edited:
You mean, use an Access deployment tool, like Inno or SSE, to create an exe installer?
No, sorry for not specifying that. We use a self-created EXE (C#) as a startup program for our Microsoft Access application. This ensures that the necessary files are copied from the network to the client, searches for/finds the installation location of MsAccess.exe, checks whether it is 32-bit or 64-bit, creates a trusted folder entry if necessary, and more.

We created our own utilities library, that includes an Access deployment tool, by compiling vb.net programs. None of our users tinker with the hidden batch scripts. If they were to deviate from protocol and break something, they would pay dearly for us to fix it. We once had a creative user who changed the system date on his workstation to enter back dated transactions. That ex_user is no longer around
Were you referring specifically to me? If so, I'm afraid I don't quite follow...
 
Personally I would never issue a batch file to a client for any reason whatsoever.
There could just be some clown who alters a batch file, causing a sequence of errors that I would be obliged to fix. I would always create the batch file and then convert it into an EXE file before issuing.
If you use a PowerShell script you could sign it with a certificate and thus protect it against execution if it has been modified.
 
Last edited:
We don't bother with checking FE versions because our users always run a copy of the latest master FE version that's stored on the server.
Are you saying that they don't run their own personal copy of the FE?
 
I guess you missed the point of why the FE ensures it is the current version when it opens.
anybody can mess with a .bat file.
they can see where the Fe is being copied from.
they can explore and what else they can do.

so, yes, i miss what is the purpose of your .bat file.
for what you know, it can copy a rogue db.
 
anybody can mess with a .bat file.
Only if they have permission to update it. What is security for? Besides, people should be aware that messing with software distribution is a firing offense.
 
Are you saying that they don't run their own personal copy of the FE?
Their desktop shortcut runs a batch script that copies the latest master FE to their workstations and launches the copy.
 
Their desktop shortcut runs a batch script that copies the latest master FE to their workstations and launches the copy.
What stops the user from opening the file he downloaded yesterday directly instead of using the shortcut to run your batch file?
 
Only if they have permission to update it. What is security for? Besides, people should be aware that messing with software distribution is a firing offense
.bat file is an ugly, Jurassic approach. very easy to pry into.
it's your approach anyway.
 
.bat file is an ugly, Jurassic approach. very easy to pry into.
it's your approach anyway.
then use VB Script. I was not pushing this method only pointing out the flaw in relying on a loader to do version checking.
 
What stops the user from opening the file he downloaded yesterday directly instead of using the shortcut to run your batch file?
The copy is downloaded to a hidden folder. If they deviate from protocol, their employment will be terminated.
 
Last edited:
.bat file is an ugly, Jurassic approach. very easy to pry into.
it's your approach anyway.

We can also write a vb.net console app that does the copying and loading, and compile it to an exe. Here's one I did for backing up the data.

Code:
Imports Microsoft.VisualBasic.FileIO
Imports System.Environment
Module Module1

    Public Sub Main()

        If GetCommandLineArgs().Count <> 3 Then
            Console.WriteLine("Missing Source or Destination folder, or too many arguments")
            Exit Sub
        End If

        Dim strSource      As String = GetCommandLineArgs(1)
        Dim strDestination As String = GetCommandLineArgs(2)

        My.Computer.FileSystem.CopyDirectory(strSource, strDestination, UIOption.AllDialogs)

    End Sub
 

Users who are viewing this thread

Back
Top Bottom