Refresh front-end of Access database from server

[icsupt]

I have a split database that many people use. Whenever I make changes to the front-end, I have to have each of the employees reinstall the front-end. Basically, it takes them less than 30 seconds to do, but I still think it could be easier.

Currently I post the front-end on the company intranet and then have each employee delete the old icon and then SAVE TARGET AS to their Desktop for the new icon.

What I'm looking to do is to have a executable file that when they click on it, it grabs the front-end from the network, saves the new icon over the old icon on their Desktop.

Can you think of any way to accomplish what I'm asking?

For this purpose, let's say:
The path to the network where the front-end lies is \\abcsql

The front-end file name is: abc.mdb

Thanks in advance.

 

[ByteMyzer]

Why not incorporate this function into the network logon? For example, if your intranet controller is named MyServer, and the local directory where the front end resides is C:\Localdir, you could add the following lines to \\MyServer\Netlogon\Everyone.bat:

@echo off
copy \\abcsql\abc.mdb C:\Localdir\ /y

 

[icsupt]

Thanks for the quick response.

That is one option, but I really don't want to add it to their network logon. I just want to be able to send them a link via email, have them click on it and then reinstall the icon onto their desktop.

Is there a way I can just send them a link to a file that will automatically reinstall the icon onto their desktop?

 

[ByteMyzer]

Did you mean the icon, or did you really mean the FE-mdb file itself?

The one problem with the method you propose is that it relies on the end-user to manually perform the update by clicking on the link, etc. In my experience with database design and end-user scenarios, too often, the end-user will neglect the update step you direct them to, try to run the old file, and if there's a problem, call support and say "The program doesn't work."

Support: "Did you click on the link in your Email to upgrade?"
User: "Oh, I didn't see the Email"
Support: "Check your Email for the memo I sent out to everyone."
User: "I don't see it. I guess I deleted it."

The network logon method, however, is an excellent way to insure that the upgrade takes place whether the end-user remembers or not.

 

[me2you]

Try making a replica of the FE-MDB to create a replica set, so that whenever you make a change to the design master and Synchronize this set, your changes will be applied all the way round.

Peace,

me2you

 

[ump38]

I've been doing this for years and it's pretty clean though it might have to be modified a fair amount to work for you in your environment. But it provides a lot of relief for me in that I never have to worry about "are my 60+ users running the latest, greatest version."

I "front-end" all of my Access apps with an executable file (Launch.exe) created using Authorware. This could just as easily be Visual Basic. Anyway, this front-end executable actually resides on the network and users simply have a shortcut on their desktop to this. This executable (program) requests a password (which happens to be different than the true password to the Access front-end file). Upon validation, it creates a file somewhere (locally or on a personal network share).... I call mine "done.txt". It then calls a batch file off the network that copies the compacted front-end from a network location to the pre-defined location. Once all necessary files are copied from the server, the batch file deletes the "done.txt" file. While this batch process is running, the executable is looping, waiting for this "done.txt" file to be removed which indicates it's OK to open Access and launch the .MDB file which has been downloaded locally. It obviously has appropriate loop control code based on an expected limit as far as time lapsed for the batch file to complete.

This method provides a lot of added benefits because it is easily configurable at the network level by:
(1) allowing access to be easily controlled. It I need to disable access for maintenance or other reasons, I can tweak something in the control file to provide that message.
(2) allowing better performance (things run faster) because the Access front-end file resides locally
(3) making compacting of the front-end Access file practically unnecessary because the user gets the compacted version and runs it locally. The network version never really "grows".
(4) not requiring any disclosure of true file passwords, the level of security is increased.
(5) providing a single access point to what may be several different passwords on the Authorware program, multiple databases and views can be delivered without a great deal of effort.

It's worth consideration, and having things configured this way has saved my tail numerous times and made life somewhat easier. Good luck with it if you should happen to give it a go.

 

[MD5150]

I once did this very easily with one of my old Access 2.0 multi-user databases.

I simply created another local "copy.mdb" file to manage the copy process so users wouldn't have to do it manually. Just double-click the "update system" icon, or whatever I called it at the time, and a new front-end version was copied down.

If the production front-end "app.mdb" ever became corrupt or had problems, instead of repairing, they could use this utility to dump the problem front-end and grab a freshly compacted copy from the server. Of course, it's rare that only the front-end would ever become corrupt, but it also was useful for automating the version updating.

The normal local app.mdb would notify users to run the "update system" utility(copy.mdb) whenever it found a newer version ID in the backend version table.

Very clean and simple. No replication, no emailing, no security issues, no networking, no third-party software, no users forgetting to update because they are forced to do so. Give it a shot. Hope this help.

Mike

 

[Ed2020]

I use and MS-DOS batch file to achieve the same thing. A small VB app would be just as easy to create....

Ed Metcalfe.

Please do not feed the trolls.....

 

[easyit]

Hi,

I use batchfiles to. they are easy to maintain. For example:

************
echo off
c:
cd\
if not exist C:\DCW\ mkdir C:\DCW\

cd DCW

rem copy fe database to C if there is a new version.
if not exist "DCW_VERSION1A.txt" copy "N:\CCC\DCW_001.mde" "c:\DCW\DCW_001.mde"

rem copy the versionfile if necessary
if not exist "DCW_VERSION1A.txt" copy "N:\CCC\DCW_VERSION1A.txt" "c:\DCW\DCW_VERSION1A.txt"

rem cpoy fe DB if it doesnt exists at all
if not exist "C:\DCW\DCW_001.mdb" copy "N:\CCC\DCW_001.mde" "c:\DCW\DCW_001.mde"

REM Start the application:
"C:\Program Files\Microsoft Office\Office\MSACCESS.EXE" "C:\DCW\DCW_001.mde" /WRKGRP "N:\CCC\MDWfile\DCW_001.MDW"

exit
**********

When deploying a new version of the fe you simply change the versionnumber in the batchfile and ofcourse the name of the versionfile.

 

[MoLaker]

I also used a batch file, but I carried it just a bit further.

Within the BE database I maintained a table containing the application version number. In the opening form (I happened to have used a modified Switchboard) I included the version number of that build in a label. I then had the opening form check the version number in the BE and compare it with the number in the form's label. If they didn't match, the user was told to update their FE and the application would then close and could not be used. The user would then run the batch file which simply copied the new FE to the local workstation and they were good to go.

When I had a new version ready, I would place it on the network for the batch file to pick up and then manually change the version number in the BE. The next time users opened the application, they were prompted to "Refresh" their application.

Incidently, there was another benefit from using this method. As some of you might be aware, MS Access has been known to get corrupted sometimes. In our case, it was nearly always the FE that got clobbered. When that happened, the user could "Refresh" their copy and be up and running without having to bother us poor down-trodden techies.