OT: Brainstorming: How to handle sw-updates

[Otto]

To all,

I would like to open a thread “brainstorming” about the best way to handle software – updates for our own software at client side.
Best regards,
Otto

[dutch]

Dear Otto,

For LAN network, I put copy from file server to local drive everytime the user login. We can update the latest version to a file server without interrupt user job. Then just let the user to log off or restart windows, that's all.

Regards,
Dutch

[Otto]

Hello Dutch,
thank you for your answer.

Code: Select all  Expand view

We can update the latest version to a file server

How do you handle these updates?

Thanks in advance
Otto

[Otto]

Sometimes it is necessary to change dbf-file structures or indexes and to block old versions to have still access to your data. How could this be handled?

Best regards,
Otto

[driessen]

Otto,

I can tell you a little bit how I do the job.

During the installation, I install a small EXE-file on the local PC. The only thing this small EXE-file does, is checking if there is an update on the server available (checking size, date and time). If so, the update (main EXE-file and other file if necessary) is copied to the local PC. After this check (and copy if necessary) the main application is started.

At the start of the main application, I check if there is a new version of the small EXE-file available on the server. If so, the small EXE-file is copied to the local PC too. Then the main application continues.

After both checks, my local PC is always updated automatically when an update becomes availble. The update has to be installed on the server only.

Sorry if my English is not very understandable, but I did my best.

Good luck.

[Otto]

Hello Michel,
Thank you for sharing.
I do have some more questions.
How do you start your small-exe and how your main application.
And how do you prevent that old versions have access to your data?
Best regards,
Otto

[TimStone]

Hi Otto,

I created a program that I'm installing to the run directory on the "file server". It does several tasks automatically. One of them is to check for, and download, updates from our main server when they are available. Then when the Client signs into the program, they are alerted a new update is available and told to run the ClientUpdate program which is in their start buttons. That program simply copies the new .exe file from their file server to their workstation. I may automate this also. One idea posted previously was to have the start .exe actually be a routine that checks for an updated file, and if it exists, then it is copied over. Then the main client program is started. I may do the same.

[James Bott]

Everyone,

Why do you feel the need to have local copies of the EXE? It only takes a couple of seconds longer to load from the server than locally, and it only has to be done once per use so it seems that the time difference is really insignificant.

Michel,

>At the start of the main application, I check if there is a new version of the small EXE-file available on the server.

Why do you need a new version of the small EXE? Can't it just check the file date and time of both the local and the server versions?

Otto,

>And how do you prevent that old versions have access to your data?

You could do this with an INI file. Just store the current version number in the INI file and check it with the EXE. During the update process, you also install a new INI then older versions will refuse to run.

Regards,
James

[TimStone]

I can now report how I handle this ... successfully !

On my "server" I have an application that runs in the background. It has timers, and it has several functions:
1) Check the main server, see if the customer is eligible for any updates, and if so, and they are available, download them. The updates are in a zip file, and it will extrract them and place them in the proper location on the customer's server. It will also log the version into a tracking file.
2) Perform backups "after hours" of all data files to a pre-determined location
3) Upload any accumulated data to FTP sites based on a pre-set schedule.
All of this activity is logged so it can be reviewed if there are any problems.

On the client workstation, I use a small "run" exe. First it checks the installed version of the program on that workstation, and it compares that to the update(d) version on the server. If it is newer, then it copies over the primary .exe file. If there is no difference, then it simply moves to the next step which is to WinExec( ) the primary program.

I prefer having a client installed on each workstation for many reasons including differing configurations.

In effect, this gives me fully automated updating. I have a central program that allows me to track the clients, their subscription status, etc., to post keyfiles to my central server, and to upload newer releases of my software. I can also shut off systems when people ask for credit and then don't pay. I can also make changes which are reflected on their computers within minutes.

It all works quite well.

[Otto]

Hello Dutch, James, Tim and Michel,

Thanks again for sharing your knowledge. These points from you I will at first insert in my new “liveUpdate”

From Dutch
An own download directory where the updated files are stored
Advantage: download does not affect the current work

From Michel
An update client but also a possibility to update the update client through the main program.
Advantage: the possibility to update the “update clients” allows the changing of the update modus if necessary

From James
Running exe from the server – Open question: what if some users do not check out?
INI-file for version numbers

Tim
Updates are zip files – maybe more secure than exe files?
Small “run” exe
The update should be able to track the clients, their subscription status, etc.,

I started today with the coding of the download client.
I found a nearly ready solution published by Biel.

Thanks again and best regards,
Otto

[James Bott]

Otto,

>Running exe from the server – Open question: what if some users do not check out?

I'm not sure what you mean by check out?

James

[Otto]

Hello James,
I mean if the exe is in use by a workstation which does not log out.
Isn't the exe write protected then?
Best regards,
Otto

[James Bott]

Otto,

>I mean if the exe is in use by a workstation which does not log out.

OK, I assume you mean this would be a problem when trying to update the EXE? If so, then you have a worse problem than when using local copies. You have no way of knowing if local copies are in use. You could update the server copy, but then you have the situation that users running the local version during the update would prevent DBF modifications. Or, if there were no DBF modifications, you still could have some users running the old version while users running the app after the server update would be running the new version. Many users will leave a major app running for days so some users may not get the update for days.

If all users are running the server EXE, then everyone must be logged out before the server EXE can be updated. This also allows you to make DBF modifications. You can also be sure all users are using the same version at all times.

James

[Otto]

Hello James,
I have prepared an other question - I answer your post in my next.

Does someone have an idea how to handle this situation?
The software is release and then updates are published.
Is there a way to keep the different users up to date if you do not publish every time all the files?
What if a user does not switch his PC on before 20.1.?
Release 1.1.2009 A.exe B.exe C.exe
Update 1 10.1.2009 C.exe
Update 2 12.1.2009 B.exe
Update 3 15.1.2009 B.exe
Update 4 18.1.2009 A.exe
Update 5 20.1.2009 A.exe
Thanks in advance and best regards,
Otto

[James Bott]

Otto,

>What if a user does not switch his PC on before 20.1.?

This is solved by running all EXEs from the server.

James