Alias includes double space, but picklist only has one

[PavoGa]

I searched but not did not find this particular issue, so apologize for missing it if there is a thread on it.

The problem: the data source for a dimension has a description used as an alias that includes a double space:
(using '.' in lieu of a space).
"Lost in..Space" instead of:
"Lost in.Space"

The alias attribute stores the former. However, when used in a picklist, it displays and uses the latter. Yes, it is bad source data, but an odd manifestation to me of eliminating spaces. An export from a cube using the alias on the dimension has the double spaces; the same export of the picklist value in the cube (say a mapping cube) has the single spaced version of the alias.

Before anyone asks, also inserted an extra space just to see if TM1 had an issue with only double spaces:

"Lost in...Space" but still:
"Lost in.Space"

Anyone run into this? Is there some secret solution or setting that tells TM1 to use the alias as stored, stop consolidating multiple spaces into one, etc?

[burnstripe]

Spaces are ignore by the TM1 server, so if an element was called "Lost in Space" or Lost in Space" both would be recorded by the system as LostinSpace.

I guess when it's inserting the spaces back in it's treating all consecutive spaces as one space.

I'm not aware of a method to prevent this behaviour

[PavoGa]

Spaces are ignore by the TM1 server, so if an element was called "Lost in Space" or Lost in Space" both would be recorded by the system as LostinSpace.

I guess when it's inserting the spaces back in it's treating all consecutive spaces as one space.

I'm not aware of a method to prevent this behaviour

This is a value stored in a attribute string measure; the spaces are retained. The problem is as described above, the alias is stored with double spaces but in a picklist is displayed with only one and stored accordingly if the alias is used. Look at the example I provided. That is what is happening.

We typically use the setting to store the element name, but this is a user-facing item for excel exports and they have bad data in the source for the alias. We are looking at stripping out double spaces when writing the alias. Just wanted to know if anyone else had seen the problem.

[burnstripe]

I understood the example but it still boils down to the fact that in tm1 that all the alias/element names are stored without spaces in the backend. So even though the alias displays with multiple spaces those spaces are irrelevant to the backend.

Lost in space
Lost in space
Lostinspace

Would all be stored as lostinspace.

This is conjecture, but when tm1 is generating the picklist it's perhaps when it's repopulating the spaces for visual representation its treating all connected spaces as one singular space.

It doesn't help you with a fix, but it does mean the problem should be easily repeatable for the IBM help desk to investigate and perhaps resolve in a future fix patch.

[MarenC]

Hi,

This won't help either but I vaguely remember a situation where element names had double dot at the end, so for example, Please Select.. or No Data Available.. and this double dot caused various issues with the data. Just can't exactly remember what those issues were!

Not directly related to your problem but thought it worth mentioning. The solution to the double dot issue was to remove them completely!

Maren

[PavoGa]

Hi,

This won't help either but I vaguely remember a situation where element names had double dot at the end, so for example, Please Select.. or No Data Available.. and this double dot caused various issues with the data. Just can't exactly remember what those issues were!

Not directly related to your problem but thought it worth mentioning. The solution to the double dot issue was to remove them completely!

Maren

I think we ran into that as well. We still use the dots, but eliminated the double dot scenario, which is most likely what we will do in this case: scan and remove all double spaces before storing the alias.