If you're not already committed(smiley) to using Git, you might consider the Deltanji source code management tool from my employer, George James Software. One of its features is the ability to manage deletion of code components (e.g. classes, routines, files, lookup tables, HL7 schemas etc) and propagate those deletion downstream in whatever workflow  you have configured (e.g. DEV, QA, STAGING, LIVE).

The documentation is misleading about this.  It says:

When you upgrade Caché to a new version, existing Query Plans are automatically frozen.

And later:

The earliest upgrade that performs this operation is an upgrade to 2017.1.0.

What it needs to say is:

The earliest upgrade that performs this operation is an upgrade from 2016.2.0.

The docs do use 2016.2 as the "from" version in their example, but not in a way that communicates how this nice feature won't help with upgrades from pre-2016.2 versions.

@Brendan Bannon - please draw this to the attention the InterSystems documentation team.

Above I've deliberately linked explicitly to the 2017.2 doc rather than to "latest" because I hope that in due course the latter will get corrected.

A bit more info on the answer from @Jeffrey Drumm

Here's how the relevant part of the 'Environment, Documentation and Proxy' section of Studio's Tools\Options dialog starts out:

In this state I can use the standard 'SOAP Wizard' add-in but it is served by the private web server of my Cache server installation. I'm testing from the Windows desktop this runs on.

I also have an instance of IIS on that Windows host, and the IIS is correctly configured to serve Portal and documentation pages from both http://localhost/ and https://localhost, plus from http://localhost/cache111 and https://localhost/cache111

Back in the Studio Options dialog I set the checkbox and start trying some value-pairs in the now-active Address and Port fields. Here are my results:

AddressPortResult of launching add-in
localhost80Success
localhost443White page, presumably because HTTP is requested from 443
localhost/cache11180CSP Error page, which reveals that the CGI variable CACHE_URL has the malformed value http://localhost:80/cache111:80/isc/studio/templates/SOAPClientWizard.csp
https://localhost443Works from Studio 2017.2.1 but fails from Studio 2014.1.1 and displays a page headed "Navigation to the webpage was canceled".
https://localhost/cache111443Fails from Studio 2014.1.1 as above. Gives CSP Error page from Studio 2017.2.1, which reveals that the CGI variable CACHE_URL has the malformed value http://localhost:443/cache111:443/isc/studio/templates/SOAPClientWizard.csp

Note too that if we enter a value for Address but leave Port blank the dialog files a value of 80 in the Port field. This can be seen when the dialog is reopened.

Conclusions from above:

  1. Templates and add-ins can be served from a server other than the Private Web Server as long as they are served from the root.
  2. Studio 2017.2.1 can fetch templates and add-ins using HTTPS when correctly configured. This is not true of some earlier versions of Studio.

No, a variable name cannot contain the underscore character, because that character is the concatenation operator. If it was allowed in a variable name, how would we interpret this, for example?

WRITE TICK_TOCK

Is it concatenating variables TICK and TOCK, then writing out the result? Or writing the value of a single variable named TICK_TOCK.

If the utility you refer to is expecting you to supply data values in variables whose names match the SQL column names, then the developer of the utility hasn't accounted for the fact that SQL column names can contain underscores but Caché variables can't. So the utility needs fixing.

For Windows the link http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCI_windows#GCI_windows_upgrade gets you to a short section titled "Caché Upgrade Installation".

For other platforms the principle is the same. Stop the Caché instance you're going to upgrade (or at least be prepared to allow the upgrade procedure to stop it). Then run the installer script in the same way as if doing a new installation. Pick the existing instance you want to upgrade.

I assume you are using Caché on Windows, and you are launching Terminal from the Cube on the local desktop of the PC where Caché is running.

In this case the security settings of the %Service_Console service (System > Security Management > Services) are what you need to adjust.

Enabling only "Unauthenticated" will mean that you don't get prompted for username/password, and your Terminal session will report $username="UnknownUser". But the security settings for UnknownUser will also have to allow that account to get to the programmer prompt. If they don't, your Terminal session won't start.

Enabling only "Operating System" will mean that provided a Caché user account exists that matches the Windows account you are logged into the desktop as, your Terminal session will report that username as its $username. Again, the Caché account will need sufficient permissions to get to the programmer prompt.