Hi Knut, This will only work if $SEARCH_RESOURCES is either not present in any of the ASN files used by the IDF or if it's set to resources_excluded. Hope this helps. Regards, Daniel

Hi Daniel, Oh the chaining of USYS.ASN's ..... One day there might be a command to get all settings (and where they're set (as in which ASN file))... hopefully! Thanking you. Knut

Hi Knut, Thanks for the info. And you are welcome. There's a note in What's New in Uniface 9.7.01 that "[b]y default, Uniface is now configured to use the standardized approach for compiling outputs and deploying applications. Uniface reads its own resources from archive files (UAR), and writes all compiled objects to the resources directory." And "[t]he classic deployment approach is still supported, but you need to explicitly configure your application for this." For details see: Reconfigure Uniface for Classic Deployment Hope this helps. And I'll mark this topic as "solved" now. Daniel

Hi Daniel, Maybe - just maybe - the Uniface installation program should ask me if I'd like to use standard or classic deployment...?? Just a thought.... :-) Knut

Knut said Hi Daniel, Maybe - just maybe - the Uniface installation program should ask me if I'd like to use standard or classic deployment...?? Just a thought.... :-) Knut

I'm afraid that this decision is not up to the installer. In Uniface 10 the support of the Classic Deployment will be removed completely. And it was thought that it might be a good idea to change the default in Uniface 9.7 to Standardized Deployment so that users become accustomed to this. Hope this helps. Daniel

Uniface 9.x will be around for quite some time - Uniface 10 for existing customers is still a number of months away. Then, adding complete regression testing to the project - I'd say we're talking at least 2017 before anything would be / could be considered with regards to Uniface 10. In order for us to even consider switching to the standard deployment - we'll have to modify our deployment scripts and fully test those too... Somehow I don't think we're "The Lone Ranger" out here - so the assumption that it might be a good idea is just that - an assumption.... Anyhow, all has been compiled and ready for testing now - so all good. Knut

The only reason I would willingly convert to from classic deployment to any other method is if there was an actual benefit to doing so. In the meantime, I will continue to believe that we are only changing for the sake of changing. Now, if it came with the promise of "hot deployment", then I would be more than happy to use the new method. I think I remember that being a promise for Uniface 9.2....

Hello, I think they called this deployment warm (no hot yet, sorry). Nevertheless I wanted to share our experience with this. We have switched to resources while migrating from U8 to U9.3. The main reason was, that classic deployment uses .dol and .urr files. This was bringing us headache for very long time, because we were unable to "patch" the application if we needed to change any signature or global object (i.e. menu). Now we're quite happy with it, since we can change almost anything (menu, global procedure, signature etc) and we can distribute it to our customer. The only action that is needed to be done by customer(s) is to quit the application and start it again - this can be done in any order... already running application has the "pre-patch" functionality, and re-started applications is patched already. (dol and urr were locked, while resources aren't locked) Kind regards, Zdeněk

I agree, we have written a web service which can be used to pull modified/new uar files from our system to the customer server and thence out to the client machines.  This allows us to patch 'automatically', and changes to previously locked 'global' objects are now possible.  Since the uar files are applied in the order found in the asn file, with the first found object being used, we are even capable of running two copies of the system (patched and unpatched) from the same code, so that users can unit test the patch before we apply it to the live system.  Changes to the database structure are harder to manage, and frequently require an 'install' or manual roll out, just to make sure that all processes are clear before updating the database. (Although even when adding new fields, as long as they are not mandatory, you can 'get away with' warm updates).  It is worth considering an interface with UROUTERMON in the update routine to close out any running userver processes to ensure the server at least is up to date, but other than that hot update is as do-able in Uniface as anything else I can think of.  Iain

I agree that standardised deployment is the way to go. I'd also like to point out that it is relatively easy to mix and match. Currently our app uses classic deployment, but by setting $SEARCH_RESOURCES = resources_first then you can have Uniface check archives/folders listed in the [RESOURCES] section and if it fails to find a match then it will fall back to the classic locations.   Andy