PSA: the following things about SQL/MULTI VARA and such may break your scripts in V12

Discussion created by Carsten_Schmitz on Feb 14, 2018
Latest reply on Feb 15, 2018 by Michael_Lowry
Let it be known:

If you aggregate an SQL VARA and a regular VARA into a MULTI VARA, and then run PREP_PROCESS_VAR on the resulting MULTI VARA, and then run GET_PROCESS_INFO(&DATA_SEQUENCE#, ROWS) on the resulting "data sequence", AE 10 would say the result is "1" (because it would count the header from the original SQL VARA), whereas version 12 says the result is "0".

Because "0" is technically correct, there will be no incident report.

Thought that was very specific? How about this one?

If you use the LENGTH() function on an array element rather than an array (which, let's be clear about this, is WRONG, you should be using STR_LENGTH() in this case), and the array element contains a number, the result in Automic V10 would be the contents of said array element (i.e. the number), wherein in version 12, the result is "0" (INC00220156, before I realized that the usage was wrong in the first place, but I still insist this should be a runtime error and NOT a successful function call with the result "0").

If you think this is very, very, very, extraordinarily specific, and never ever happens, rest assured that this is the kind of issue that our users are currently discovering with testing their V10 scripts on V12, and we are struggling to justify, and the more you dig, the more of these seem to creep up.

This unfortunately confirms to me that the script language is indeed a pile of hack.

And thus, the real PSA here probably is: You don't just have to test genotypes of jobs when you go from one UC4 version to the next. If you have more than the most basic of scripts, you're well advised to test every single one of them.

That is all.

(Disclaimer: The opinions expressed above, especially on piles of hack, are purely my own).