Persistent...Aliases???

[PavoGa]

Ran into some issues with aliases that had supposedly been cleared, or could not be reassigned to another element. So wrote a process (FINDER) that, for a given alias value, loops through dimensions and hierarchies testing for the alias' existence, the alias it exists in, primary element name and the index value of the principal element name. The results were bizarre to say the the least.

Here are the test steps and results:

1. Principal Element: 2018 Calc
2. Cube views of the attributes setup for dimname:dimname, Leaves and Alias_Testing attribute of DLBR Alias
3. Assign Test_Ty as the value for the alias in base dimension (dimname:dimname)
4. Ran FINDER and Test_Ty is found in the dimension, but not in the hierarchies. In PAW, the alias value is displayed in the hierarchies.
5. Remove Test_Ty and ran FINDER again. Still finds it.
6. Saved data. Ran FINDER. Found non-displaying alias Test_Ty.
7. Changed alias in dimname:dimname to Blofeld.
8. Blofeld is found in dimname:dimname by FINDER, but not in the hierarchies.
9. Without changing anything, ran FINDER again searching for Test_Ty. Which is promptly found on the same element and in the same alias attribute. Blofeld is still displayed in the cubeview and and element name in the subset in dimname:dimname and the hierarchies!
10. Removed Blofeld. All three cube views no longer display Blofeld as element names or in attribute.
11. FINDER: Blofeld not found!!!
12. FINDER: Test_Ty is found!!! It is nowhere to be seen in the cube views. Saved Data and it is still nowhere to be seen but FINDER still locates it.
13. Tried manually assigning Test_Ty to another element. Failed, indicating the alias has already been used.
14. Saved data. Test_Ty still found by FINDER
15. Blofeld assigned to a different element without problem. Removed it. Ran FINDER. Not found.
16. Assigned Test_Ty to 2018 Calc in the Alias_Testing hierarchy.
17. FINDER still finds Test_Ty in dimname:dimname, but not the hierarchies.
18. Ran a separate process (CLEANER) that created a view on the attribute cube for 2018 Calc/DLBR Alias, performed a ViewZeroOut and used ElementAttrPutS to write Test_Ty to the Leaves hierarchy.
19. Ran FINDER and found Test_Ty in dimname:dimname, Leaves and Alias_Testing.
20. Ran CLEANER but did not write any attribute values.
21. Ran FINDER and found Test_Ty in dimname:dimname, Leaves and Alias_Testing. Test_Ty is not displayed in any cube view. Additionally, FINDER cannot find Test_Ty in any alias element.
22. Saved Data on the model. FINDER, if nothing else, is determined and finds Test_Ty again in all three hierarchies. In the cubeviews, Test_Ty is nowhere to be seen.
23. Ran CLEANER, but to write Test_Ty to 2019 Calc. Minor error reported: "cannot be set as Attribute"
24. Ran CLEANER, but to write Test_Ty to 2019 Calc on Alias_Testing hierarchy. Minor error reported: "cannot be set as Attribute"
25. Ran CLEANER, but to write Test_Ty to 2019 Calc on dimname:dimname using CellPutS. Got "Cell type is consolidated" which is what one gets when using CellPutS writing an alias that won't go.
26. Ran CLEANER, but to write Test_Ty to 2019 Calc on dimname:dimname using AttrPutS. Got "cannot be set as Attribute".
27. Bounced the server.
28. FINDER can no longer find Test_Ty.

Not really happy with this. We do use "floating" aliases to designate time elements for rule calculations and periodically those shift from one element to another. Apparently, a server restart clears the air, so there is that to mitigate the problem.

[PavoGa]

Okay, this appears to have been discussed in other threads, just did not catch one of them. Apparently forcing a dimension recompile is at least one method for resolving this.

Still think it should be fixed.