Batch file for updating local frontend Access database copy

[arnelgp]

Here are a couple of excepts from probably the best technical MS Access book ever written. Too bad there isn't an ACE edition. This is from my third copy of the book. The first was stolen, the second was lost to a fire and so I bought it again about 5 years ago. It was published in 1997 and still makes fascinating reading. The first two copies were $49.99 each, the last one was $5.00 I think and worth every penny. Get a copy if you can locate one.

 

[DickyP]

View attachment 121361

Couldn't endorse this recommendation more! Basically it is still good for everything except additional data sizes added and system limits.

Wouldn't be without mine, which is the second edition. Mine cost £46.99 , which was lot of money in 2001 when I bought it!!

 

[AHeyne]

whether Full version or runtime it will work.

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.

 

[Cotswold]

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.

 

[Gasman]

You want the querydefs to be uncompiled to force them to obtain new statistics and recalculate the execution plan each day.

I can understand that, if the BE changed it's data structure in some way, but if any change was just an increase in data?

 

[Gasman]

As I said, when the db is compiled, so are the querydefs if they were left that way. You want the querydefs to be uncompiled to force them to obtain new statistics and recalculate the execution plan each day.

Here are a couple of excepts from probably the best technical MS Access book ever written. Too bad there isn't an ACE edition. This is from my third copy of the book. The first was stolen, the second was lost to a fire and so I bought it again about 5 years ago. It was published in 1997 and still makes fascinating reading. The first two copies were $49.99 each, the last one was $5.00 I think and worth every penny. Get a copy if you can locate one.

Picked up a copy from Amazon for £10.79.
Just hope I get to read it.

 

[BlueSpruce]

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

 

[AHeyne]

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...

 

[AHeyne]

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.

 

[BlueSpruce]

Were you referring specifically to me? If so, I'm afraid I don't quite follow...

No, was just explaining what we use over here.

 

[arnelgp]

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.

 

[BlueSpruce]

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.

 

[arnelgp]

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.

 

[BlueSpruce]

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.

 

[BlueSpruce]

.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.

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