Page 1 of 1
SCAN not working
Posted: Thu Oct 22, 2009 2:02 pm
by ccierpik
I'm not sure what I'm missing here, but I'm using the following to filter out a listing of accounts:
# Get principle element name instead of using alias
sTM1Acct = GetPrincipleElementName('All_IS_Account', v4) ;
# Filter out non general ledger accounts
# Scan(substring, string)
If (Scan('Case Sale', sTM1Acct) > 0) ;
ItemSkip;
EndIf:
This seems pretty straightforward, however, it is not filtering out the accounts with case sale in the name. For example, for the sTM1Acct = 'TOTAL CASE SALES', the result is 0 (I output to an ASCII file to verify what the result was in TI) instead of.
I know that Scan is a pretty basic function so I'm surely just missing something very obvious. I'm using 9.1 SP3 (Build: 9.1.30000.340). Thanks for your help.
Re: SCAN not working
Posted: Thu Oct 22, 2009 2:42 pm
by Marcus Scherer
it works with
DimensionElementPrincipalName
and an ; after your endif
Regards,
M.
Re: SCAN not working
Posted: Thu Oct 22, 2009 9:41 pm
by lotsaram
Your problem is that the SCAN function violates the general TM1 principal of case insensitivity.
Try this:
If (Scan('CASE SALE', Upper(sTM1Acct)) > 0);
ItemSkip;
EndIf;
Re: SCAN not working
Posted: Thu Oct 22, 2009 10:30 pm
by David Usherwood
My view would be that TM1 is case insensitive as regards _code_ (rules and TI) but not as regards _data_. After all, one does, sometimes, want to distinguish 'a' and 'A'.
Re: SCAN not working
Posted: Fri Oct 23, 2009 5:53 am
by Alan Kirk
David Usherwood wrote:My view would be that TM1 is case insensitive as regards _code_ (rules and TI) but not as regards _data_. After all, one does, sometimes, want to distinguish 'a' and 'A'.
I would agree. However it's disturbing that TM1 can be a tad inconsistent on what's a match and what's not. A direct comparison of two string variable values is not case sensitive, for example, as s1 in the code below shows. And yet this would also be data.
While on the subject of such inconsistencies, Scan (as an example) is also
space sensitive (which I would concur that it should be), and yet as we know a straight comparison of variable values is not (s2 in the example below).
Code: Select all
# Will return 4
l1 = Scan ( 'def', 'abcdef');
# Will return 0
l2 = Scan ( 'def', 'ABCDEF');
#Will return 0
l3 = Scan ('def', 'a b c d e f');
# Will return Match
If ( 'def' @= 'DEF');
s1 = 'Match';
Else;
s1 = 'No Match';
EndIf;
# Will return Match
If ( 'def' @= 'd e f ');
s2 = 'Match';
Else;
s2 = 'No Match';
EndIf;
#Proof
AsciiOutput ('F:\Temp\Outputs.txt', NumberToString (l1), NumberToString (l2), NumberToString (l3), s1, s2 );
Re: SCAN not working
Posted: Tue Jan 17, 2012 2:43 pm
by Steve Vincent
Just got caught by this myself, the help files make no mention of case sensitivity;
SCAN
This is a TM1® rules function, valid in both TM1 rules and TurboIntegrator processes.
SCAN returns a number indicating the starting location of the first occurrence of a specified substring within a given string. If the substring does not occur in the given string, the function returns zero.
Syntax
SCAN(substring, string)
Argument
Description
substring
The substring you are trying to locate.
string
The string within which you are searching for the substring.
Example
SCAN('scribe', 'described') returns 3.
I will raise a request with IBM to get the documentation updated because next to nothing else in TM1 gives 2 hoots about case and it is important people know about it. Yet another inconsistancy in the way inbuilt functions are handled :/
Re: SCAN not working
Posted: Tue Jan 17, 2012 4:14 pm
by Duncan P
Does anyone know of any other functions apart from SCAN that are case and space sensitive? It would seem to make sense to present a comprehensive list.
Re: SCAN not working
Posted: Wed Jan 18, 2012 8:48 am
by Andy Key
Filter by Wildcard in subset editor is space sensitive.
Re: SCAN not working
Posted: Wed Jan 18, 2012 9:53 am
by Alan Kirk
Andy Key wrote:Filter by Wildcard in subset editor is space sensitive.
So are Long and SubSt.
Back on the subject of case sensitivity, the arguments to TimSt are as well.
I've been meaning to add these to my Documentation Deficiencies thread and will do so when I get a chance.