Hi, Mario -

You'll need to provide some additional information. We are not sitting alongside of you at your desk, so you need to be much more descriptive of your environment/setup/processes. You have not given us any useful information on which to base any suggestions. For example:

Is the app installed locally on each machine or on a network-accessible drive/folder?

What is the process that occurs when "an update has been released from development"?

Typically, when a new set of app PBD's/DLL's is made accessible (installed), each user must exit the app and restart it. Is this occurring?

Best regards, John

Thank you John for your reply.

You're right, information is needed.

Let's start with the concerns you raise.

The application is "installed" on each machine; Actually how we work is this way; There are several applications - the same modules that are separated into different folders. Each one contains its executable and its pbd's.
In another different folder we have all the DLL's (runtime), and when we run the initial application (menu) it starts in the folder where the DLL's are located.

We are working with computers with Windows7, Windows10 and Windows11.

When an update is released, the executable and the PBD's are copied to their respective folder (this is on a server); and through a third-party program; We update each of the workstations.

Every time an update is made, we ask users to exit the executable and re-enter

Hope this was usefull.

Regards.

Anyone who tell me why?

I have ruled out the problem could be caused by the third-party application that copies the updates.

I have directly copied the updates to my pc, and still the updates are not seen.

They are process updates, in the recording and generation of information; but no updates that can be seen (they're background but not of form).

Regards.

Pinning an application to the taskbar or start menu merely creates a shortcut file in a system folder. It doesn't make a copy of your application.

Thanks Roland;

I know that; but the problem still here.

Do the file sizes and the date/time stamps on the application PBD's/DLL's get updated when the update/distribution process runs?

Is the server configured as a failover primary/secondary or replicated server pair?

We have one customer that utilizes these for their production, user acceptance test, and test environments. When they install an update to their production servers, for example, they must copy the new files to BOTH of the replicated servers, because if they update files only on the server that is currently inactive, the users will not see any updated files. This sounds like what is happening in your case - but I'm not a Server Administrator, so this is purely a guess at this point.

Does this issue happen with any other applications that are installed and made available on the same server(s)?

There has to be something else going on that you may not be aware of and have not told us about. You may need to work with your Network and/or Server Admin's to troubleshoot this issue further, because it does not appear to be a PowerBuilder-related issue.

Best regards, John

Thanks John;

I am the system, network and apps admin.

All I've been reviewed and discarded.

Our upgrade process is quite simple; nothing complex.

Our system is made up of several modules (each module is an executable); one of those executables is the login and main menu system; the other executables are invoked from this main menu.

We have a main folder, in that folder are the login and main menu executable; also have several subfolders; in which are the executables and pbd's of each module.

The executable that is pinnend in the Windows status bar is the one with the login and menu; and this is causes the other executables don't updated; do not work correctly (it is as if something is left in memory at the operating system level) which means that the changes are not made.

The file sizes and the date/time stamps on the applications PBD's/DLL's get updated in the client's side; are  the same we test and release in development side.

Regards;

Mario Francisco