If it is deployed in LAN and client/server architecture is OK, then you can use the new PowerClient feature that we plan to introduce in PowerBuilder 2019 R3.

If you need to deploy over Internet or to cloud server, then you should use PowerServer.  https://www.appeon.com/products/powerserver

Hi Luis,

So far as I know, you would have to write your own.  That is what we did at my shop.

Each of our applications has an entry in the database which is linked to using the application's AppName property.  Among other things, the database stores the names of the application's files.  Upon launch, the application compares the file dates of its files on the local disk where it is running with the files in the central repository.  If any of the local files are older than those in the central repository, it initiates the application synchronize function.

The synchronize function constructs an INI file that includes the app path of the app to be updated as well as paths to each of its files and the corresponding file in the central repository.  This information is all drawn from the application's database entry.  The application then launches an update application and quits.

The update application uses the information from the generated INI to update all the requisite application files, and then re-launch the application once the files have been updated, and having re-launched the application, it quits.

You need Windows API to compare file dates (FindFirstFile, FindClose, CompareFileTime functions), and is heavily dependent upon the environment in which you are running your applications.  In our case, we have had a very stable, well controlled environment and our process works extremely well for us.  The process is a bit cumbersome, but it can be done once and forgotten about.  We put it in place somewhere in the 1999-2000 timeframe and have really not done much to it since.

Andy

Greetings, Luis - 

We use a simple .BAT file. Old school, I know, but it just works.

On an internal, public network share/drive, we place all of pieces that are needed to run our app: The exe, pbd's, dll's. ico's, bmp's, jpg's, etc., along with a .BAT file. The batch file performs several XCOPY commands; each copies one of the various types of component files to a designated destination folder: C:\ProgramData\OurAppName\, for example. Each XCOPY command uses the /D /R /Y command flags so that only files that have a newer date/time stamp than the version in the destination folder get copied.

The last thing the batch file does is issue a START command to run the app from the user's local destination folder. The entire .BAT file is only 30 lines long, including comments.

Each user's desktop icon for our app points to the .BAT file. Each time a user starts the app, the .BAT file runs, any new or updated versions of files are copied to the local destination folder, and the app runs. Simple.

Regards, John