Long strings in TI; difference between 8.2 and 9.0/9.1

Post Reply
User avatar
Alan Kirk
Site Admin
Posts: 6606
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2.0.9.18 Classic NO PAW!
Excel Version: 2013 and Office 365
Location: Sydney, Australia
Contact:

Long strings in TI; difference between 8.2 and 9.0/9.1

Post by Alan Kirk »

I'm posting this so that if anyone else gets bitten by it in the future, they'll be able to search for it.

There's a difference between 8.2.12 and 9.0/9.1 in the way long strings (strings which exceed the 254 character limit in pre-9.4 versions) are handled in TI. I don't know where 8.3 / 8.4 stand on this.

Consider the following code:

Code: Select all

l_Counter = 1;
s_String = '1234567890';
s_StringLong = '';

While ( l_Counter < 30 );

     s_StringLong = s_StringLong | s_String;

    l_Counter = l_Counter +1;

End;

AsciiOutput ('D:\Temp\LongString.txt', s_StringLong);
{Edit: The ASCIIOutput wouldn't have worked under 9.1 even if the process hadn't barfed; I forgot that under 9.1 the output path has to be either a UNC reference (\\Server\Share\Path) or a reference to a local drive. You can't use mapped drives the way you can in 8.2.12. I've therefore modified the code from Y:\ to D:\, which represents a local drive on the server.}

In 8.2.12, which I'm used to, you'd get up to loop 25, at which time you'd have a 250 character long s_StringLong variable value. When T.I. hit loop 26 it would say "nuh-uh, another 10 characters won't fit, I'll just ignore that", and it would do the same thing with loops 27 to 30. When you open Y:\Temp\LongString.txt you'll find a 250 character long string.

In 9.0, however, you get "Process Was Aborted". When you check the log file you find "System stack overflow, process terminated". You won't get to the AsciiOutput line.

Oh yay, progress. Instead of having a truncated string, which in many cases would be a trivial and non-material error, let's crash the entire process instead.

Now I grant you that the 8.2.12 method wasn't ideal; you could end up having a lengthy and frustrating time debugging code if values are truncated without warning. To my mind the ideal would therefore be for a cautionary warning log to be generated in such a case.

But ploughing the whole process into the farm because a message string might have exceeded the ridiculously short string length limitation in pre-9.4?

Hmm, I'm not sure what that achieves aside from smatterings of profanity.

The solution, which should be unnecessary but thanks to Iboglix isn't, is to check the length of the resulting string before you concatenate anything to an existing one (by checking both lengths) if you think there's any chance at all of it exceeding the 254 character limit.

Like the system used to do for you, automatically and without aggravation, in 8.2.12.

As I say, progress is a wonderful thing.
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
Post Reply