That's certainly a useful tip. I wonder if it would have helped in a situation we assisted an Ensemble site with last year. They'd upgraded their DEV and QA environments from 2013.1 to 2015.1 but their LIVE was still on 2013.1. Then they amended an HL7 schema in DEV, exported it, imported it to QA, verified it worked, and finally loaded it to LIVE, where it broke the production.

The cause turned out to be a change made in 2014.1 and documented in a bullet point here. Yes, they had been unwise not to retain a QA or pre-live staging environment on the exact Ensemble version that LIVE was running.

I take your point about keeping up with the technology curve, but it's no good the next release of your app using all the whizzy new features of the latest Caché version if you're not able to deploy it to your customers until they can be coaxed to upgrade. Yes, you can use the new features as a carrot to entice them to upgrade, but meanwhile you probably have support commitments to them that mean occasionally patching the app release they're currently using.

At analysis time you can choose which packages to include. The webapp whose time-based graphical output I showed above doesn't let you filter a whole-namespace analysis to view only the stats for a single package. But the Structure101g Studio tool gives a lot more power. For example, here's a drilldown into the top-level packages:

Overall bar length is code size. The red portion is the XS of the package.

Thanks for the feedback Ben.

I'm familiar with System Defaults, and we actively try and promote their use when we talk to Ensemble users about this issue. However, the way that Portal defaults to filing configuration item settings into the class means that it's all too easy to do this by accident. In contrast, to add/edit a System Defaults type of setting requires significantly more effort within the UI. Surely a better job could be done here?

I expect Prodlog 94592 already has the name of George James Software all over it, as we've been lobbying on this issue since the very beginning. While we wait, we've devised some techniques that allow Deltanji to leverage the OnConfigChange classmethod that a 2012.1+ production class can be given. You can read about them here.

John

What Caché version are you working with?

The use of SCHEMA in this way is documented at

http://docs.intersystems.com/cache201513/csp/docbook/DocBook.UI.Page.cls... but not at http://docs.intersystems.com/cache20141/csp/docbook/DocBook.UI.Page.cls?... so it appears to have been introduced with 2015.1. I didn't find any mention of it in the 2015.1 release notes though.

If your READ from wrappercomp raises an error (e.g. end of file) you don't have anything in place to catch this error, CLOSE wrappercomp and USE olddev once more. I suggest you add some code (for example a TRY/CATCH block) to do this, and also to tell you what the error was. That information might help you find out why the wrappercomp pipe didn't work as you expected.