Caché Upgrade Checklists - InterSystems Documentation

Caché 2012.1 Upgrade Checklist= 1, the result set columns can be automatically swizzled when referencing the row type properties if the type of the columncorresponding to the property is a swizzleable type. For example,SELECT Spouse from Sample.Person where Spouse IS NOT NULLIf that statement were prepared as a dynamic SQL statement with %ObjectSelectMode = 1, retrieving the Spouseproperty will trigger swizzling and an oref will be returned. However, if %ObjectSelectMode is 0 then the property willbe returned as a simple ID value.For streams, SQL will return a fully qualified Stream OID (SOID) value. This is true for embedded SQL and dynamic SQLwhen %ObjectSelectMode is 0. The fully qualified SOID value can be swizzled manually using##class(%Stream.Object).%Open(). Stream columns selected by executing a dynamic SQL statement preparedwith %ObjectSelectMode = 1 will automatically swizzle.An error in dynamic SQL caused stream columns to automatically swizzle when %ObjectSelectMode was not 1. This hasnow been fixed. Applications that took advantage of this behavior will have to change their processing to use%OBJECT(streamcol) or to manually swizzle the stream SOID using %StreamObject.%Open.2.2.7.7 Dynamic SQL %Print ChangesThe %Print utility method implemented for result sets will now quote the output value if the value contains a line feed.Before this, the value would only be quoted if the value contained the delimiter character.2.2.7.8 Changes To SQL DECODE StatementA change has been made to the SQL DECODE function. Prior to this change, DECODE returned the same type as thefirst return argument in the DECODE function call. It has been changed in this release to return the most compatible typeof all the potential return values from the function.Consider the following function call:DECODE(999, ' ', 1, 0.7)Caché considered the return type of this to be INTEGER. When .7 was returned as the value through the xDBC driver, itwas truncated to 0 because the type was supposed to be INTEGER. (By contrast, Oracle does not consider the value 1 tobe an INTEGER, but rather FLOAT(38) which allows the .7 to be returned to the client intact.)Now, the possible return values in the function call above are 1 and .7, so in this case the function would returnNUMERIC(1,1) The following data types are compatible and are specified in order of precedence (highest to lowest):VARCHAR, DOUBLE, NUMERIC, BIGINT, INTEGER, SMALLINT, TINYINT. A DECODE function call that couldreturn a NUMERIC, INTEGER, or TINYINT; the return type will be NUMERIC because it has the highest precedence ofthe three types. Due to the type given to literal replaced arguments in xDBC queries, if the above function was included inan xDBC query column, the type reported would be NUMERIC(18,9).2.2.7.9 Host Variables Disallowed In The View Of A QueryHost Variables have never been allowed in the query of a view. Their attempted use sometimes caused unexpected andnon-descriptive errors like, SQLCODE = -51, when attempting to compile these statements. If you attempt to reference ahost variable in a view's query, or in a CREATE VIEW or ALTER VIEW statement, you will now get an SQLCODE =-148 and an appropriate error message in %msg.2.2.7.10 Changes To ROWCOUNT In TSQLA problem has been corrected with the TSQL SET ROWCOUNT feature. If any application relies on the current behaviorof ROWCOUNT in Caché TSQL, it will have to be modified.For TSQL code such as:28 Caché Upgrade Checklists