Here is a method I developed back in the PB 6 time period that allows updating the application files on a network drive while users are using it.

I created a stub exe that the user's shortcut points to. There are two folders under the folder containing the stub exe. The folder names are Version1 and Version2. The stub exe reads an .ini file to determine which folder contains the current version and then runs it.

When a new version is deployed, it is copied to the Version# folder that is not current. Once the files finish copying, I would then change the folder name in the .ini file. We would then send out an email to all users telling them that they should exit the app and immediately run it again.

The application would set the AppName database parm to the version folder name. This allowed us to run the sp_who stored procedure to determine who was running what version. Occasionally a user would have a shortcut to one of the version folders. These were discovered by the sp_who results.

Personally I do not like compiling to PBDs and rolling them out. There is no versioning of a PBD file in the build process so you really have no idead which version of the PBD file a user is running.

Having said that we do roll out ad-hoc reports for customers through a PBD, the reports themselves are all versioned so that negates the PBD file version proiblem. As Rolnad said I think the PBD file may well be blocked from overwrite if the APP is runnign and has opened the PBD.

Finally I would now advise using the PowerClient to deploy your application. This pretty much deals with the issue. The PBD files are versioned and in this method so the code is fully protected. The PBDs are ecrypted too so it's very diffcult to hack open your PBDs. From a security and IPR protection this is vital.

To answer your original question: I would think that you might get away with copying out a new PBD file, withthe only issue being if the EXE App has the PBD file open.

Hope hat helps.

David

Please find attached Zip contains image of ORCA and application.

What we do is create an "EBF" PBL.  Empty at first but when we make changed to objects we copy them to them to that PBL and create a PBD from that.  We store that in a table in the database.  There is code in the app that looks for that and when it finds it downloads it and then does a SetLibraryList call to add that PBD to the beginning of the library search path.  That allows us to update code without having to redeploy the EXE or any of the PBD.   The entries in the database are versioned so that the application can look to see that it's version of the EBF PBD is out of date and download the new one.

There are a number of things that can't be updated this way though.  Any of the global variables such as the transaction object and in the case of PFC apps the PFC app manager.   That's because they all get loaded into memory before our code that checks for the EBF PBD gets a chance to run.

Note we did that because something like PowerClient (https://www.appeon.com/products/power-client) wasn't available when we first wrote that.  If that's a possible solution you could use I'd highly recommend it.  It allows you to update the entire application dynamically.

If you generate a PBD for all libraries including the one that contains the application object, no code objects will be in the EXE.

I haven't tested this for recent versions but in the past PBD files that had been loaded into memory were locked.

I agree with Chris, but I do not believe he fully answered your question.

The application object contains the declarations for the app's global variables and global external function declarations, so any change to those would necessitate a re-deploy of the .exe. Also signature changes (new/different arguments) to methods in other objects that get called by code in the application object, because the method bindings have to be updated.

While I understand your desire to not having to require users to exit the application, I think there are times where it makes sense to do so. Database/schema changes, database server maintenance, for example. The commercial app I work on combines a five-minute "heartbeat" feature with a quick check of an application status value in a configuration table. When this value is changed to indicate the app is to be disabled, the next heartbeat check causes the app to display a critical message that the app will shut down and the gives the user a chance to save their data. If a customer needs to install a new release of the app or make the system unavailable for maintenance, this logs all users off within those five minutes. As Chris is fond of saying: Food for thought.

Best regards, John

Hi Vipin;

  Normally, an App Build for a new EXE is done by the developer(s) when getting ready to Unit Test before shipping the PB App of to the QA Team. This build is basically a "Production Candidate" (IMHO) for the QA team to fully test. So I personally (as a developer) would perform an App EXE build on my PB IDE machine and then do a quick "sanity test" on this before shipping it over to QA.  Food for thought.  HTH

Regards ... Chris