Long strings in TI; difference between 8.2 and 9.0/9.1
Posted: Tue Jul 14, 2009 11:18 pm
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:
{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.
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);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.