I want to automate downloading an update in the form of an ACCDE.
I am able to check a URL for an updated ACCDE and download it to the user's pc.
I cannot change the ACCDE which I am running to the update, unless I close the ACCDE. This would require running another program which would simple replace the existing ACCDE with the new ACCDE.
Is there a way to do this replacement without another program. I thought of using ACCDE and ACCDR, in other words, if I use ACCDE download the update as ACCDR and next time the software runs it will use ACCDR. The next update woud be ACCDE etc. Seems very kludgy.
I use a starter app which look like a splash screen.
This runs from a desktop shortcut and automatically checks for a new version at the specified url.
If the current version is the latest available, it starts the main app and the starter app closes automatically.
If a newer version is available, the main app is archived and the new version is automatically downloaded and opened as above. No need for the user to login again
The starter app also checks for a newer version of itself in the same way. If that is also found it is downloaded and the new starter app runs on the next occasion.
As far as the end user is concerned, this just looks like a splash screen. It all happens automatically and is very fast.
Most of the code used is included in my example app. You could combine it with what you have already if you like the idea.
Assuming that the original software is A.accde, the obvious solution would be to have a second file B.accde, which will handle the copying of the updated .accde.
1) In A.accde we check for an update and it it exists then calls B.accde
Code:
Dim APP As Access.Application
Public Sub subOpenDB()
Set APP = New Access.Application
APP.Visible = True
APP.OpenCurrentDatabase "Pathname of B.accdb"
End Sub
2) Inside B.accde, we close A.accde
Code:
Dim OtherDB As Object
Dim strOther As String
strOther = "Pathname of A.accdb"
Set OtherDB = GetObject(strOther)
OtherDB.Application.Quit
3) Move and rename .accde update to A.accde
EDIT: Just saw your Starter App suggestion. Will look into it.
I use a starter app which look like a splash screen.
This runs from a desktop shortcut and automatically checks for a new version at the specified url.
If the current version is the latest available, it starts the main app and the starter app closes automatically.
If a newer version is available, the main app is archived and the new version is automatically downloaded and opened as above. No need for the user to login again
The starter app also checks for a newer version of itself in the same way. If that is also found it is downloaded and the new starter app runs on the next occasion.
As far as the end user is concerned, this just looks like a splash screen. It all happens automatically and is very fast.
Most of the code used is included in my example app. You could combine it with what you have already if you like the idea.
Colin, I would like to make the process transparent to the user. I do not want to prompt the user to download. If there is a new version, the user will download it. No need to prompt to a Website.
Colin, I would like to make the process transparent to the user. I do not want to prompt the user to download. If there is a new version, the user will download it. No need to prompt to a Website.
As described in post #5, that's precisely what my FE updater does. The whole process is seamless and invisible to the end user.
The link given in post #3 covers part of the process but without the automation
For internal distribution, I use a simple batch file. The user always opens the app using the batch file and the batch file always downloads a fresh copy of the FE. The FE always checks its version against the BE to make sure the correct version is being opened. I'm not at my computer so I can't paste the file but if you search here you should find it or some other similar one.
A process is transparent when the user is always informed about what is currently happening.
An automated process should run without user intervention, for example no stupid message boxes that need to be confirmed.
Now you would have to look at how to bring the two together.
Here's the batch file.
It is just four statements with no error checking. The md and del don't raise an error if the directory exists and if the file doesn't exist so the batch file works for both existing and new users.
md = make a directory - the first time a user runs the batch file, this makes a directory on his local c: drive. If your users run from Citrix or RD, then you need a slightly different batch file so that the directory references are to the users personal directory.
del = deletes an existing copy of the FE. This is to avoid the overwriting warning.
copy = copies the master FE from the server to the local directory. If someone messes up the master copy of the FE, this could raise an error but it is an unrecoverable error and the user needs to contact IT to fix the problem.
The final statement opens the applcation.
Code:
md c:\DwgLog
del c:\DwgLog\DrawingLog.accdb
copy "\\BSCCTIMBERLINE1\Timberline Office\AccessApps\Data\CommonFE\DrawingLog.accdb" c:\DwgLog
c:\DwgLog\DrawingLog.accdb
When the FE opens it compares the FE version in the FE version table to the FE version in the BE version table and only continues if the two match. If they don't, an error is displayed and the FE closes.
There are several pros to always downloading a fresh FE and no cons that I can think of since the FE is usually pretty small and downloads in a blink.
1. Updates are automatically installed. The user does nothing.
2. Since the FE is sent in an uncompiled state, each querydef will be recompiled and a new execution plan created and saved. This keeps the stats from getting stale and so the query is always as efficient as it can be based on the current state of the BE.
3. Bloat is not an issue unless you're doing something crazy in the FE with temp tables. If you use temp tables, make sure they are necessary and if they are, use the concept of a "side end" which we have described multiple times or you can ask here if you need to.
4. The chance of corruption is also minimized. Remember, Access ALWAYS updates the FE during your use of it. That s why the changed date on the FE always changes. So, each day the user starts with a pristine copy of the FE.
Now we come to mid-day updates. Usually, if the fix is small and not critical, if the FE is currently open on some computers, having them using the old version but new opens getting the newer version isn't a problem. If the update is critical, you have to get everyone out of the database before you push out the new update. There are techniques for doing this that involve running a timer that checks a table or a file for instructions. Search or ask if you need the code. Typically, only an emergency update to the FE would be made during normal working hours. Most updates should be made evenings or weekends to not interfere with the work of your users.
PS, I always rename my .accde to .accdr
It is just one more block to the accidental updating of the FE.
Here's the batch file.
It is just four statements with no error checking. The md and del don't raise an error if the directory exists and if the file doesn't exist so the batch file works for both existing and new users.
md = make a directory - the first time a user runs the batch file, this makes a directory on his local c: drive. If your users run from Citrix or RD, then you need a slightly different batch file so that the directory references are to the users personal directory.
del = deletes an existing copy of the FE. This is to avoid the overwriting warning.
copy = copies the master FE from the server to the local directory. If someone messes up the master copy of the FE, this could raise an error but it is an unrecoverable error and the user needs to contact IT to fix the problem.
The final statement opens the applcation.
Code:
md c:\DwgLog
del c:\DwgLog\DrawingLog.accdb
copy "\\BSCCTIMBERLINE1\Timberline Office\AccessApps\Data\CommonFE\DrawingLog.accdb" c:\DwgLog
c:\DwgLog\DrawingLog.accdb
When the FE opens it compares the FE version in the FE version table to the FE version in the BE version table and only continues if the two match. If they don't, an error is displayed and the FE closes.
There are several pros to always downloading a fresh FE and no cons that I can think of since the FE is usually pretty small and downloads in a blink.
1. Updates are automatically installed. The user does nothing.
2. Since the FE is sent in an uncompiled state, each querydef will be recompiled and a new execution plan created and saved. This keeps the stats from getting stale and so the query is always as efficient as it can be based on the current state of the BE.
3. Bloat is not an issue unless you're doing something crazy in the FE with temp tables. If you use temp tables, make sure they are necessary and if they are, use the concept of a "side end" which we have described multiple times or you can ask here if you need to.
4. The chance of corruption is also minimized. Remember, Access ALWAYS updates the FE during your use of it. That s why the changed date on the FE always changes. So, each day the user starts with a pristine copy of the FE.
Now we come to mid-day updates. Usually, if the fix is small and not critical, if the FE is currently open on some computers, having them using the old version but new opens getting the newer version isn't a problem. If the update is critical, you have to get everyone out of the database before you push out the new update. There are techniques for doing this that involve running a timer that checks a table or a file for instructions. Search or ask if you need the code. Typically, only an emergency update to the FE would be made during normal working hours. Most updates should be made evenings or weekends to not interfere with the work of your users.
PS, I always rename my .accde to .accdr
It is just one more block to the accidental updating of the FE.
but since my application runs on a local network, downloading the .accde each time although it has its advantages, would require an Internet connection, which would be a bit restrictive, so I decided against it.
If Internet is available I will check for an update. To do this I use an extra .accde. The process is as follows and if someone is interested in the code I can publish it.
The main .accde is run and if Internet is available it downloads a file with the Version number.
The Version number is compared against the Version number of the current DB and if different it downloads the Updated .accde and invokes the second .accde, which closes the first .accde and copies the Updated .accde to the correct place. The original .accde can be copied int a backup file in case there is a problem.
The main .accde is run and if Internet is available it downloads a file with the Version number.
The Version number is compared against the Version number of the current DB and if different it downloads the Updated .accde and invokes the second .accde, which closes the first .accde and copies the Updated .accde to the correct place. The original .accde can be copied int a backup file in case there is a problem.
My approach is a single click approach. It automatically checks whether there is an update and if there is an update the current .accde must close so that it is substituted by the updated .accde and is reopened automatically.
I have had problems with pending Access tasks. I manage the tasks with GetCurrentProcessId which provides the PID of the current task.
The following declaration is needed to use the command.
Public Declare Function GetCurrentProcessId Lib "kernel32" () As Long
Ditto and the only reason for that click is to allow program admins to delay installing an update if they request that.
Otherwise, the whole process is completely automated.
In my case there are two steps involved.
!. The program admin is automatically alerted when a new version is available from my website. He/she downloads the update at a time that suits them. Nobody else gets the alert as there may be additional actions required before the new version is deployed
2. Once the new version is ready for all users, it is copied to an update folder on the network. When end users run the starter app from the desktop shortcut it automatically transfers the latest version to their local C drive as already described. No action required by end users - totally automated.
I prefer not to close the ACCDE FE so it can be replaced. That step is eliminated using my approach
The updated .accde is on the Web and is only downloaded if there is an update. I investigated Pat's suggestion of copying the .accde each time, but does not work well, if the file is non the Web,
The download does not take place within the actual Access app. The app calls another .accde which copies the updated .accde to the folder where the original .accde resides. The process is transparent to the user and in my case, if an update exists it is downloaded, unless the user has no Internet connection.
The user is informed that an update has taken place, but is not asked to allow the update. It is a simple replacement of the existing .accde file, with the updated .accde file.
You also need a second db to manage the .accde replacement.
You can do anything you want. No need to justify your solution.
All we're saying is it is safer to open a "launcher" than to open the actual database and have to close it to overwrite it, not to mention the "overwrite" being more complex. The "launcher" also allows you to always download a new version if that is desirable. Everything happens behind the scenes. The user isn't notified since he has no choice. The app decides what to do based on the version compare. Allowing people to ignore an update doesn't sound like a good solution.
PS, the "launcher" has two version tables. One linked to the local FE and the other to the BE.
