How do you distribute the updates? (1 Viewer)

[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

 

[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 happen to use a batch file to do run the app at the client site. The users have a shortcut that runs a batch file on the server and the batch file downloads the master copy of the FE. What you're doing is fine but you can't ask. Just do it.

If you can't trust the users to get the file in the right place. Ask to run a GoToMeeting session while they do it so you can make sure they do it correctly.

 

[Pat Hartman]

@Ranman256 Running the FE from the server adds overhead. Running from their local PC is more efficient.

 

[Ranman256]

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

 

[Pat Hartman]

If you are pushing the FE to each PC, yes, the PC not being on would be a problem but that is not the way it is normally done. The download of the new version is triggered by the user trying to run his shortcut or open his current version. The app checks it's version and opens or switches to the download process automatically so you never have to push anything. The user pulls the first time he opens the old version.

the_Doc_man has written extensively on the Windows/DOS reasons for running locally. The users may not be complaining but running from the server, puts an unnecessary load on the LAN. So, running locally is like being a good neighbor because it minimizes the LAN traffic which ultimately helps everyone.

 

[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

 

[Pat Hartman]

@shoji There are times for politeness and times for firmness. You can't have ONE user using an outdated version. this is not like a stand-alone application where it makes sense to allow people to update or not. Even Office has to allow users to decide to update or not. The difference with your application is that even though we are communicating using the same web page and we both have instances of Office 365 installed on our PC's, we are NOT sharing data and it is the data sharing which makes the update of your FE imperative whenever there have been changes. Sometimes the old FE won't work because you have also made a schema change. Sometimes you will have fixed a bug but the old app will still allow users to add bad data. Updating an application that uses a shared database is NEVER optional.

@bastanu @isladogs has shared a great deal of the tools he as developed. But, you are right, to use his exact method, you would need a website as the intermediary to download the new FE from. You can still so the same thing by sending it via email. The user still has to choose the target directory to download to and follow the directions on extraction. The distribution after that is easy enough and there are several free databases that can help with the distribution. I use a very simple batch file which I have posted multiple times. It is four lines of code with no error checking. You can add error checking if you prefer but the two initial actions which are make-directory and delete the old version do not raise errors if they fail. So that means the same .bat file can be used for both new and existing users. The third line is the only point of failure and that is the line that copies the FE from the server to the local directory. That would fail if the new FE was not found for some reason. I don't remember the exact error but it seemed clear enough that I didn't need to create a custom message. The fourth line opens the downloaded database. The database itself compares the local version table with the linked version table to determine if they match. If they match, the app opens. If they don't, it raises an error message and closed the database. To make this work, you need to create a shortcut on the user's system and then the client's admin needs to email the shortcut to the new users with instructions to save it to their desktop. Whether you use the .bat method or the db method, you need to get SOMETHING to each user to initiate the action and that may be why you elected to go with the server side method. It is less efficient but otherwise fine because it accomplishes the primary purpose of not sharing the FE, assuming the directories are private, meaning userA can't access the directory holding userB's FE.

 

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

 

[Pat Hartman]

You needed to include code and tables in the application when you built it in order to help to control the distribution. I suggest that you take a look at the articles @isladogs has written BEFORE asking him for personalized help. I'm sure that if you don't understand something and can post a specific question, one of us will help you with it.

 

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