How do you distribute the updates?

[shoji]

I am curious to know how you, experienced developers, handle the distribution of the updated programs to your clients.

This is how I am doing -- a bit cumbersome, but working:
This client company of mine is located in a different country. Whenever I write an update, I send this file to someone in this company. He will place the update in a certain folder on the server as instructed by me. By the way, he is the most computer literate guy in this company who even doesn't know how to move files on the server. Therefore, asking him to distribute the update to every user is a bit too much.

My program (FE) has a table that holds the version number. Each time the program starts, it compares the version number of the program (update) saved in this particular folder on the server with itself. If the updated program has a higher number, it prompts a message to the user, asking if the user wants to update the program. If the answer is yes, it triggers a program, Updater, again saved in a certain place on the server, and then quits itself. The Updater now takes over, deletes the program that sent the request, copies the updated version into where the original program was located, and then starts the new update before it closes.

Recently, I got a report from this guy who said the update halted so he had to force quit. It turned out that they upgraded Office to Microsoft 365 and this new Microsoft 365 had a bit more stringent security mechanism and a warning popped up during this update. He didn't realize there was a pop-up warning screen behind the program and thought the update was somehow in an infinite loop. All he had to do was to go to this warning screen and click "Open". Well, after all, they are my customers and thus they are kings! I have to anticipate all these big and small unexpected situations.

In an environment where you cannot expect clients to do any "sophiscated" procedures, how would you handle the distribution of your updates?

Thank you.

Shoji

 

[Ranman256]

all my users have their own Front End on their server.
I have an access db to copy the update to each folder, then when the user opens it , the db relinks their tables to their server backend.

 

[monheimx9]

My program (FE) has a table that holds the version number. Each time the program starts, it compares the version number of the program (update) saved in this particular folder on the server with itself. If the updated program has a higher number, it prompts a message to the user, asking if the user wants to update the program. If the answer is yes, it triggers a program, Updater, again saved in a certain place on the server, and then quits itself. The Updater now takes over, deletes the program that sent the request, copies the updated version into where the original program was located, and then starts the new update before it closes.

I have a very similar procedure
The only difference is that I download/uploads versions on a RESTful web API service that is called by a python program
Otherwise, exactly the same as you

 

[Ranman256]

cant update if their pc is off. Tho some do use their pc. But those on server cant see any noticeable slowdown.

 

[isladogs]

As each of my commercial apps are used in many different organisations, I use a system which requires no site visits and minimum effort on both my part and that of the clients / end users

Updates for all my commercial apps are uploaded to my website
Program admins are notified automatically when this happens.
He/she then downloads the latest version and runs it.
This relinks to the BE on the network server & performs any 'housekeeping tasks' - again automatically

The program admin then copies the updated FE to a designated folder on the server.
When each user clicks the desktop shortcut, this opens a starter app which checks for a newer version on the server.
Where that exists, the new version is automatically downloaded to each user's workstation overwriting the original.
The new FE then opens automatically

As far as the end user is concerned, the process is fast & seamless

 

[shoji]

Thanks for your responses. I have a few questions.

@Ranman256
So, each user has a copy of the program on the server? Not that everyone shares the one and same copy of the program on the server?

@monheimx9

The only difference is that I download/uploads versions on a RESTful web API service that is called by a python program

Does this mean that each end user has a python program on their PC?

@Pat Hartman

You can't have your app ASK if it is OK. If the versions don't match, the app needs to automatically perform the update.

I was just following the standard (or wasn't it?) way to do the updating. If I were an end user, I would like to be asked before the program is updated. But I understand your point.

@isladogs
Your setup is like that of a big software company. I am one-man operation and don't have enough resources to go that far on the web.
But I have a question about your set up:::

When each user clicks the desktop shortcut, this opens a starter app which checks for a newer version on the server.
Where that exists, the new version is automatically downloaded to each user's workstation overwriting the original.
The new FE then opens automatically

I take it that this "starter app" is different from the main Access program. Is this starter app sitting on a local PC or the server? Is this app another Access program or something else?

Thanks.

Shoji

 

[bastanu]

I also use a starter app similar to Colin's, here is a link to it:

FBA DB Launcher - MS Access front-end deployment tool - ForestByteApps

ForestByteApps - A place for Microsoft Access code samples and utilities to make your life easier. Free Microsoft Access tools and sample VBA code

forestbyte.com

Cheers,

 

[isladogs]

Thanks for your responses. I have a few questions.
@isladogs
Your setup is like that of a big software company. I am one-man operation and don't have enough resources to go that far on the web.
But I have a question about your set up:::

I take it that this "starter app" is different from the main Access program. Is this starter app sitting on a local PC or the server? Is this app another Access program or something else?

Thanks.

Shoji

Hi @shoji
If you mean that my approach sounds professional in its execution, then I'll take that as a compliment.

My approach is similar to what you're already doing but is probably less complex

For info, I have been a sole developer for the past 11 years. Setting up a process like I described isn't that difficult or time consuming
Furthermore, the advantage of the starter app approach is that it can be reused for each new application with minimal changes

The starter app is a separate Access app in the same folder as the Access FE. The desktop shortcut opens the starter app.
I use a borderless form 'floating on the desktop' i.e. with the Access application window hidden because it looks like a splash screen.
I like the effect ...though its certainly not a requirement.
Here is an example:

If you like the idea, I can send you links to articles, YouTube videos & example apps where I use part of this approach

 

[monheimx9]

Does this mean that each end user has a python program on their PC?

Yes, but it is not what I would call a secure way of doing this
The major drawback it's of course is that the "updater.exe" (it is just a python script that has been compiled using pyinstaller) has to be updated as well, and the easiest solution that I found is to make sure that the Access Database copy the updater from a Network Share
Also, it's a rudimentary solution, but it works for a small business where all users are behind a VPN, on the same network.
I was tempted by the solutions that are proposed in the other posts here above because obviously I had done some research before, but on the other hand I also wanted to make a home-made solution just for the fun of it
If you want I can copy you the code for the Client and the Server, it is a simple piece of software and I repeat, NOT secure if you plan to distribute outside a private network

Cheers

 

[mgav]

Hi @shoji
If you mean that my approach sounds professional in its execution, then I'll take that as a compliment.

My approach is similar to what you're already doing but is probably less complex

For info, I have been a sole developer for the past 11 years. Setting up a process like I described isn't that difficult or time consuming
Furthermore, the advantage of the starter app approach is that it can be reused for each new application with minimal changes

The starter app is a separate Access app in the same folder as the Access FE. The desktop shortcut opens the starter app.
I use a borderless form 'floating on the desktop' i.e. with the Access application window hidden because it looks like a splash screen.
I like the effect ...though its certainly not a requirement.
Here is an example:

View attachment 102737

If you like the idea, I can send you links to articles, YouTube videos & example apps where I use part of this approach

Hi @isladogs , I would appreciate any notes/articles/links/documentation on how to set up a FE and BE with updates like you have done. I've just completed my first contractor job and am ready to distribute to the company. I'd apreciate any advice. Thanks!

 

[The_Doc_Man]

I was just following the standard (or wasn't it?) way to do the updating. If I were an end user, I would like to be asked before the program is updated. But I understand your point.

I wish to comment narrowly on this response. Shoji, have you ever noticed the way that Windows does it updates? The ONLY way you can keep a Windows system from updating is to remove it from the world wide web. Otherwise it will find a direct server or shadow server from which to draw its downloads. It will give you a time-limit on how long it will wait, and then it will just DO it. Is the Windows method something you would call "standard"?

Here is the simple answer to letting the user make a choice. A change to front-end only might not make a big difference regarding program stability. The FE-change-only cases usually mean the stubborn users don't get new abilities. BUT the moment you have a change that requires a BE update, that BE is shared among however many users you have. You CANNOT afford to let a single user hold up an entire organization because they don't want to make a change. That stubborn user becomes a road-block, which costs you and your company time and money while you are forced to sit on your thumbs until this user gets the message. It also holds up progress that might allow the company to work more efficiently than they would have using the older version that lacked certain features.

 

[KitaYama]

The ONLY way you can keep a Windows system from updating is to remove it from the world wide web. Otherwise it will find a direct server or shadow server from which to draw its downloads. It will give you a time-limit on how long it will wait, and then it will just DO it.

@The_Doc_Man With all respects, I know you're aware of it, but just to prevent others to mis-interpret your comment :

There are 3 ways to prevent windows 10 and above from auto update :

1. Turning off Windows Update Services and changing it from Auto to Manual to prevent it on each reboot
2. Block Auto updates with Group Policy Editor
   Computer Configuration > Administrative Templates > Windows Components > Windows Update
3. Block Auto Updates with Registry Editor
   HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows (adding WindowsUpdate & AU keys and a NoAutoUpdate Dword value set to 0)

There's a 4th option that I never suggest it to anyone : Using third party tools.

I've never used Windows Home version in my life. So Group policy may not be available in Home. But the other options still are.

Windows update in previous versions can be set to OFF in control panel, Windows Updates. (If my memory serves me right)

 

[The_Doc_Man]

@KitaYama
If you use your solution #1, the first manual update will reset the update setting. I learned that trick a long time ago.

If you have an environment that actually USES the Group Policy facilities, your IT staff will usually schedule your updates for you from a local relay source, but they WILL usually force the patches. Any environment that uses Group Policy to actually block updates is unaware of some of the terms and conditions in the Windows EULA regarding patching, but that doesn't matter either. If you fail to update your Windows, don't ever call Microsoft for help unless you want to pay through the nose.

See Paragraph 6 in the below link, which relates to updates. One can say that there is some wiggle room, but the last sentence is clear to me. Thou shalt update Windows when MS says to do so.

https://www.microsoft.com/en-us/Useterms/OEM/Windows/10/Useterms_OEM_Windows_10_English.htm

The REGEDIT method and the Group Policy method have the same effect if not the same path.

Not to mention that if your project is exposed to the big-I Internet, it is the most incredibly unwise way to run an unpatched Windows environment.

 

[KitaYama]

@The_Doc_Man Most corporates prevent windows update with group policy. Because if not, one morning we come to our job and none of our PCs work as they should, because of a bug in an update. Most K updates is to cover the bugs in a previous updates.
We only update Windows when the version number changes. (for example 21H to 22H). Previous versions of updates were called SP1, SP2, ....

If you fail to update your Windows, don't ever call Microsoft for help unless you want to pay through the nose.

I'm sorry, but it's not true either. They know not every update is perfect and they don't want a manufacturing system stop because of a bug in the last update. We receive a lot of support from them and none of our PCs is updated with the last patch.

Not to mention that if your project is exposed to the big-I Internet, it is the most incredibly unwise way to run an unpatched Windows environment.

Rule No.1 in any corporate I know. Don't connect a PC with sensitive data to internet. Most of our PCs are not able to connect to internet.
No matter you're up to date or not, no IT that I know risks the data.

But you missed the point. Your comment said there's no way to stop windows update and I gave you at least 2 (group policy and Registry) which none of updates can change them.
Now we are talking if it's correct to stop the updates or not?

 

[The_Doc_Man]

OK, you want "possible" whereas I wanted "wise." And as for your "coming in to find updates have wreaked havoc" I did that with the U.S. Navy for over two decades. What our IT group did was intercept all patches and test them, then put them on a distribution server when we knew they wouldn't break. Didn't matter, stuff broke anyway.

If you have an unpatched version of Windows and ask for help, the first thing they ever told US was "patch it."

 

[ebs17]

It turned out that they upgraded Office to Microsoft 365 and this new Microsoft 365 had a bit more stringent security mechanism and a warning popped up during this update.

However, a huge problem remains if the user side changes their own installation significantly and the developer cannot anticipate this, let alone check and deal with it.

With a new Access version, new registry entries would have to be written to trustworthy storage locations, as a first step.

 

[shoji]

I wish to comment narrowly on this response. Shoji, have you ever noticed the way that Windows does it updates? The ONLY way you can keep a Windows system from updating is to remove it from the world wide web. Otherwise it will find a direct server or shadow server from which to draw its downloads. It will give you a time-limit on how long it will wait, and then it will just DO it. Is the Windows method something you would call "standard"?

Here is the simple answer to letting the user make a choice. A change to front-end only might not make a big difference regarding program stability. The FE-change-only cases usually mean the stubborn users don't get new abilities. BUT the moment you have a change that requires a BE update, that BE is shared among however many users you have. You CANNOT afford to let a single user hold up an entire organization because they don't want to make a change. That stubborn user becomes a road-block, which costs you and your company time and money while you are forced to sit on your thumbs until this user gets the message. It also holds up progress that might allow the company to work more efficiently than they would have using the older version that lacked certain features.

Hey Doc,

Thanks for the comment. My client company is small and enforcing the update is not a big deal. However, a couple people are using Office 2010 for the reason unrelated to my program and my program is developed with Office 2013. They are well aware that this will become an issue sooner or later. Meantime, I am still offering an option to not update the program.

Shoji

 

[ebs17]

What has not yet been mentioned: To distribute your own software, you can also use installer programs that only require the user to answer simple dialogs; if the conditions are standardized and remain the same, you could even save on the dialogs.
As example: https://jrsoftware.org/isinfo.php

 

[Moosak]

I used the Same mechanism that you are using. But I make this simple form in the FE to take the new updated FE to the server so the old FE always check if there is a new update at the startup.

This way required just few clicks from the application manager to setup the new updates.

1. Click Browse Btn then select the new updated FE that I already sent to hem.
( Automatically it will be copied to the certain folder in the server)
2. Set the date to the date that New update will starts.
3. Select [ Start applying new updates ? ] to confirm applying the new updates.

 

[isladogs]

Hi @isladogs , I would appreciate any notes/articles/links/documentation on how to set up a FE and BE with updates like you have done. I've just completed my first contractor job and am ready to distribute to the company. I'd apreciate any advice. Thanks!

Sorry but I've only just noticed this request.
As already mentioned, I've published the steps involved in my approach in several threads here and parts of it on my website.
I can't provide the exact code I use as doing so would make my apps less secure.

In short, I do the following
1. I use an installer app (I use SamLogic Visual Installer Pro but other installers are available) to distribute all my commercial apps - both full versions and updates. The .exe files include all required files, SQL Server scripts to update the BE where appropriate and script to update the registry etc. The files are all available from hidden pages on my website.
2. For application updates, program admins are alerted automatically when opening my apps if a new version is available and the download path is provided.
This is all done in code and you can find an example app on my website showing how this is done

Web Version Checker

This example app is designed to show how users can be alerted to program updates on a specified web page.

www.isladogs.co.uk