TI Process Data Source Started Outputting Both ID and Alias Since 2.1?!

[raeldor]

We have found a problem in upgrading to 2.1+. It seems using a cube/view data source it's now showing correctly (in preview) a variable (v1, v2, etc.) for each dimension, but in the data script v1 has id for the first dimension, v2 has alias for the first dimension, v3 has id for the second dimension, etc. for views that show alias for the dimension instead of id. This is completely nuts, as now there is no consistency. It seems to be tied to the saving of the view because even rolling back didn't fix the issue until we re-saved the view after rollback.

Has anyone else seen this behavior? How has this not broken code for many, many clients?

[Alan Kirk]

We went to 2.1.3 from 2.0.9.18 (IIRC) when we went to our new servers last month and I've not seen anything like this but that said... it has been a long, LONG time since we have used views that are predefined and saved as a data source, at least for mainstream processes. For the most part we use temporary views that are generated in the Prolog which I think these days would be the most common approach since it means that you don't have "flat file" views stinking up the public Views list. You also don't have the risk of the view being accidentally corrupted since it only exists for the duration of the chore run. That would explain why if there are any issues (and I have to admit I haven't encountered any in 2.1 even in quick and dirty one-off processes where I did create a view externally rather than writing the code to build it), few people have encountered it.

The other random thought bubble would be the method / client that you used to create the view, and whether it ended up as a classic view or an MDX view. However I don't think there would be much value chasing that rabbit down a hole.

I would suggest that you change over to using the method of creating the view as a temp view in the Prolog and assigning that view as your data source; in the long term it's a safer and more robust way of managing the interface, IMHO.

[raeldor]

Appreciate the prompt reply, thank you. We use pre-defined views so that our super-user clients can control the data that's output themselves. We were allowing them to design these views and then output to CSV using them. However, since 2.1 that now seems to be completely broken. Most of the views are created using PAW now, so they are saved as MDX.

Interestingly, if saved as a native view this problem doesn't happen at all. So I think a bug has been introduced when saving MDX views that make them incompatible as TI process data load sources. We will log a bug. Thank you.

[gtonkin]

Is your alias by any chance called "Description"?

[raeldor]

Is your alias by any chance called "Description"?

No, it's called 'Name'.

[gtonkin]

Name is an intrinsic attribute and would typically return the MemberID (actual name) if you were working in a set in PAW.

What may have changed is an update to MDX that impacted the Description alias as detailed here.

Sounds like some changes were made that "corrected" some less strict implementations of MDX and through so doing impacted existing models.

I would recommend adding another alias called Caption and migrating you models to using this. Using Caption has many additional benefits like using locales to support multi-language implementations. PAW and PAfE also use Caption internally for labels like Views, Cubes etc. and these can be updated accordingly too. Caption is also recognized in Cognos Analytics and it also seems to be seamless in Apliqo.

[lotsaram]

Anything that is declared in the SELECT statement of the MDX which includes PROPERTIES to get attribute values of dimension elements will be included as an additional data source variable (that is column) when the view is consumed by TI process. I'm not sure in exactly which release this was changed.