Caché Release Notes and Upgrade Checklist Archive
Pre-2014.1 Upgrade Information
[Home] [Back] 
InterSystems: The power behind what matters   

Upgrading Caché
Upgrading from Field Test Versions
InterSystems does not support an upgrade from any Field Test version to another Field Test version, nor from a Field Test version to an officially released version. The term “Field Test version” includes any version of Caché labelled as such, or distributed to customers at the InterSystems Global Summit or other events.
Upgrading From Prior Released Versions
Customers running on any prior released version of Caché may upgrade to this version of Caché during installation. When upgrading across multiple versions, intermediate upgrade steps may be necessary depending on the inter-release compatibility requirements. The release notes for the intervening releases will contain that information.
2K block size databases must be converted to 8K format before upgrading to 2012.2.x or beyond. See Supported Upgrade Paths in the “Upgrading Caché” chapter of the Caché Installation Guide for more information.
Prior to beginning an upgrade, InterSystems recommends that an instance be shut down using standard methods — not as the result of, for example, a system crash.
After each upgrade step, the following conditions apply:
When Recompiling
There are several things to remember when recompiling:
  1. Because recompiling necessarily updates system data associated with the routine, users who recompile classes or routine must have write access to this data (^ROUTINE) in each namespace where the object being compiled is mapped. Failure to observe this requirement will result in “ERROR #302: the database is read-only”.
  2. Everything needed for compilation must be accessible in the namespace where the class or routine is mapped. For example, if a class or routine refers to a user-defined include file, this must also be mapped so it will be found by the compiler when the source is processed.
  3. By default, $SYSTEM.OBJ.CompileAllNamespaces does not compile the namespaces “%SYS” and “DOCBOOK”. If a site has classes in %SYS, these will need to be manually recompiled. Do not use $SYSTEM.OBJ.CompileAllNamespaces on a HealthShare installation.
  4. The recommendation to use features such as $SYSTEM.OBJ.CompileAll assumes that all information about dependencies between items being compiled is entirely contained within the declarations of the items themselves. For some complex applications, for example those that assemble an application “core” and then bootstrap themselves to the final version, this will not be the case. In such instances, users should create scripts to compile the code so that dependencies unavailable to the compiler are accounted for, especially in relation to schemas and domain-specific languages.
  5. Although it is not required, if a site has placed routines named [%]Z* in the %SYS namespace, InterSystems recommends that these be recompiled, for example, with
    ZnSpace "%SYS"
    Set sc = $SYSTEM.OBJ.Compile("Z*,%Z*", "ck")
Compatibility With Earlier Versions
InterSystems strives to assure that applications written for a version of Caché will run without change on subsequent versions. While this is not always possible (and therefore the reason for this document), the reverse is not true.
In general, InterSystems does not support moving an application developed for version X to a version prior to X. This applies to both source and compiled versions of the application. Exceptions to this are few and explicitly noted.
Customers writing an application that will be deployed on multiple versions of Caché should design and develop the application to use only the features on the earliest of the intended versions.
Web Application Considerations
As part of your upgrade and deployment plans, please consider the following strong recommendations from InterSystems regarding web applications:

Send us comments on this page
Copyright © 1997-2019 InterSystems Corporation, Cambridge, MA