Batch file for updating local frontend Access database copy

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

 

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

 

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

 

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