TM1 Forum

Could anyone please let me know what are the drawbacks of "Wildcard Search" in a Dimension in TM1?

Also in case of DIMIX(server_name:dimension, element), what kind of search is performed here, is it the exact Element search or a Wildcard search? Could anyone please tell,how the search is narrowed down in this case?

Thanks in Advance !

DIMIX is an exact match, taking into account that:

- all aliases are looked at
- TM1 being case-insensitive and space-insensitive

The drawbacks are that you can only search in the currently selected alias.

Also Scan() is case-sensitive, if you want to use that as a search mechanism.

Wim Gielis wrote:DIMIX is an exact match, taking into account that:

- all aliases are looked at
- TM1 being case-insensitive and space-insensitive

The drawbacks are that you can only search in the currently selected alias.

Thanks for your answer !

Well i would like to show a scenario in which I'm facing problem.

I have an import file which have 2 coloumns(vA & vR).Taking an example:

vA = 328976
VR = Mise à disposition de ressources


Now the values of "vA" needs to be inserted in a dimension(say 'DimensionD'), as an element, if & only if "vR" is found in other dimension(say 'DimensionR').
So the script i have used is:

If(DIMIX('DimensionR', vR)>0);
DimensionElementInsert('DimensionD', '', vA, 'n');
EndIf;

Also in the Prolog tab of the TI process, I have used ----> ( SetInputCharacterSet('TM1CS_UTF8');)

Now Dimix searches for 'vR' in 'DimensionR' & adds 'vA' in 'DimensoionD' for the above example.

But the thing is in 'DimensionR' there is no exact match for the value "Mise à disposition de ressources" when i search it manually. Instead there are values like:

1. RTY KP - Mise à dispo ressources
2. HJG678_KP Mise à disposition Fonction Su
3. HJG678_KP Mise à disposition FS -Recette
4. RTY KP - Mise à dispo ress. - Recettes
5. MISE A DISPOSITION RESSOURCES_RECETTES

How is this possible, that the element is getting inserted in the dimension, even when the exact match is not found considering the above 5 cases? Please let me know, if I'm missing something.

Thanks in advance for your reply !

When searching have you checked all aliases?

declanr wrote:When searching have you checked all aliases?

Yes , i have checked all the Aliases but no Luck !

Try to just copy and paste the element name into the subset editor window and see what you get.

Also, watch out for invisible characters. An article on that can be found on my website. The site changed to extension .com instead of .be

declanr wrote:Try to just copy and paste the element name into the subset editor window and see what you get.

Well, i get the error while doing it which says "Can not include the following names in the subset because they are not valid element names for the dimension" .

Maybe this was the first thing you did, but I'll mention it nevertheless. Did you try inserting some debugging code into your script? I mean, just a simple ASCIIOutput capturing the most essential things for each record, and examining the part when an erroneous insertion to DimensionD was done?

Did you try inserting some debugging code into your script?

Always a good idea. Note that 10.2.2 FP7 (and PA2 = TM1 11) include a TI debugger. I've not spent a lot of time with it yet as it doesn't play well with enlarged fonts on Dell laptops, but it's got to be a major step in the right direction. (From our records TI has been around since TM1 7.1, August 99, so good to see some progress )

daniel.havassy wrote:Maybe this was the first thing you did, but I'll mention it nevertheless. Did you try inserting some debugging code into your script? I mean, just a simple ASCIIOutput capturing the most essential things for each record, and examining the part when an erroneous insertion to DimensionD was done?

Yes, i did that. Actually there are a lot of elements in the Import files that need to be added in the "DimensionD" . But most of them are being rejected as their corresponding vR cannot be found in DimensionR. I have searched those vR manually as well in the dimension & didn't find anything even close to it. So the "Dimix" part seems to work fine atleast in some cases.

Jack, I'm not sure about the root cause unfortunately, but you could try adding another layer of checking. After the DIMIX returns a number greater then zero, you could insert another If structure where you could check the element principal names of vR and the element from DimensionR for string equality. (if you capture the return value of the DIMIX in a variable, you can use that in a DIMNM to get the corresponding element from DimensionR). If this check evaluates to true, you can go ahead and insert vA into DimensionD, and it would be interesting to capture those that return False, maybe it can help you in your further investigation.

My biggest pet hate ever being the grey area between subsets and elements.

I think that (in some versions?) subset names return a positive Dimix result that is greater than dimsz, can you check if you have a subset that has the same name as the problem "element".

This can be trapped by checking that your Dimix is less than Dimsz for a true element

Cheers,

daniel.havassy wrote:Jack, I'm not sure about the root cause unfortunately, but you could try adding another layer of checking. After the DIMIX returns a number greater then zero, you could insert another If structure where you could check the element principal names of vR and the element from DimensionR for string equality. (if you capture the return value of the DIMIX in a variable, you can use that in a DIMNM to get the corresponding element from DimensionR). If this check evaluates to true, you can go ahead and insert vA into DimensionD, and it would be interesting to capture those that return False, maybe it can help you in your further investigation.

Thanks for your suggestion. I'll try out that.

Actually, there is another scenario that i came across.

vA= 576769
vR= synchronizing available contacts

the above vA gets inserted in DimensionD. But the thing is "synchronizing available contacts" in not present in DimensionR. Instead, the value that is present in DimensionR are:


1. R-BD_FGT678_CR_Synchronisation des contacts disponibles
2. FTRE_Synchronisation des contacts disponibles
3. GHY_UT_456_Synchronisation des contacts disponibles
4. KLOI890_Synchronisation des contacts disponibles

If I translate "Synchronisation des contacts disponibles" it says "synchronizing available contacts" which is equal to required vR. So, is this thing possible in TM1, the translation part.

Wim Gielis wrote:Also, watch out for invisible characters. An article on that can be found on my website. The site changed to extension .com instead of .be

Actually, there is another scenario that i cam across.

vA= 576769
vR= synchronizing available contacts

the above vA gets inserted in DimensionD. But the thing is "synchronizing available contacts" in not present in DimensionR. Instead, the value that is present in DimensionR are:


1. R-BD_FGT678_CR_Synchronisation des contacts disponibles
2. FTRE_Synchronisation des contacts disponibles
3. GHY_UT_456_Synchronisation des contacts disponibles
4. KLOI890_Synchronisation des contacts disponibles

If I translate "Synchronisation des contacts disponibles" it says "synchronizing available contacts" which is equal to required vR. So, is this thing possible in TM1, the translation part??

Thanks for your help in advance !

Dimix will only return exact matches, if the problem string is an element pasting it into the subset editor should be error free irrespective of alias used.

Did you miss my comment on subsets just before your posts? I'd check that

It sounds like you are using the Caption attribute feature in TM1 to make your system multi-lingual which would indeed make a huge difference as I believe the other language values are treated as aliases and would explain the behavior. It would have been nice to know this fact a lot earlier in the discussion.

tomok wrote:It sounds like you are using the Caption attribute feature in TM1 to make your system multi-lingual which would indeed make a huge difference as I believe the other language values are treated as aliases and would explain the behavior. It would have been nice to know this fact a lot earlier in the discussion.

Thanks Tom !

Actually , I just saw that we are using the }ElementAttributes_}Cultures(Caption Attribute feature) for different languages , which explains the translation part.

Steve Rowe wrote:My biggest pet hate ever being the grey area between subsets and elements.

I think that (in some versions?) subset names return a positive Dimix result that is greater than dimsz, can you check if you have a subset that has the same name as the problem "element".

This can be trapped by checking that your Dimix is less than Dimsz for a true element

Cheers,

Vastly off-topic now but I had a run in with this bug / feature. You can insert subsets into subsets (via the subset editor with copy/paste of the subset names) where they act just like user defined consolidations. We had a standard process that cloned subsets (just copying elements from one subset to another) which mysteriously errored, after some digging I figured out that SubsetGetElementName returned the names of subsets which had been added to other subsets but the very next line SubsetElementInsert then errored as the name returned in the line above wasn't actually an element in the dimension.