Caché Upgrade Checklists - InterSystems Documentation

Caché 2010.1 Upgrade ChecklistThe part is a string of decimal digits optionally followed by a decimal point (.) and some fractional decimal digits.A may not include an exponent.If a routine accepts just a string that is not preceded by a and a comma, a leading minus sign, (-) is permittedto represent negative time intervals.5.2.2.7 $INCREMENT ChangesPreviously, $INCREMENT() of a variable containing a very large number would not change the value of the variablewhen the increment value is insignificant compared to the original value. Thus, successive calls to $INCREMENT() couldall return the same value, which is incorrect. Beginning with this version, this situation will cause the increment operationto throw a error instead of returning an incorrect result.5.2.3 Routine Changes5.2.3.1 KillAllObjects Takes No ActionThe function, KillAllObjects^%apiOBJ(), used to remove all object memory from the partition has been changed to ano-op. Applications can remove an object by letting the object go out of scope.5.2.4 Routine Compiler Changes5.2.4.1 Routine Compiler Skips Generated CodeThe routine compiler, ^%RCOMPIL, will no longer compile code that has been generated. Previously, if you attemptedto compile *.mac, and there existed MAC code which was generated by compiling classes, the generated class MAC codewould be compiled. This would cause the methods in that class to not be runnable. Other code which is marked as generatedwill also not be compiled. This includes .INT code which comes from MAC code and classes, and cached query code.Note:It is possible to compile a "generated" routine, but only if the name of the generated routine is specified exactlyas one of the routines to compile.5.2.5 Class Changes5.2.5.1 Namespace Changes And OREFsAssume you create an OREF to a class instance, and then change the namespace the application runs in. In prior versions,you would normally get a error when you tried to access a method of this OREF in the second namespacebecause it could not find the code to run. Caché was looking for the code in the current namespace and not in the namespacewhere the OREF was created.Beginning with this version, an application can create an OREF and change its namespace; when it attempts to use thisOREF and it will run the code from the original namespace. However, any references to global data or locks made duringexecution will be relative to the current namespace. This means that it the executing code does a %Save(), the data willbe saved it will save the data to the current namespace and not the namespace where the code is running. Similarly, a methodthat does a $GET(^Global) will look up the global in this namespace rather than the original namespace.When an application changes namespaces, it changes the visibility of data. Cross-namespace access to OREFs does notpreserve the global data visible from the original namespace. When an object is opened in Namespace A and it loads datafrom ^MyGlobal, then ^MyGlobal is expected to be in Namespace A. In changing to Namespace B with an OREF fromNamespace A, then any access by that OREF to ^MyGlobal looks for the data in Namespace B.CAUTION:Caché cannot check for this condition. The use of object references created in other namespace may resultin subtle data loss or corruption undetectable at the time of execution.110 Caché Upgrade Checklists