Report prompted multiple time

[dssd]

I have a report that is sourcing out of multiple cubes. Each cube has the same inbuilt prompt. When i run the report i get prompted 3 times with the same prompt. Can i have it in such a way that i get prompted only once and not thrice

[lucasdnd]

Your report is probably using many different parameters to store the same thing. If these 3 parameters have to receive the exact same value, they could all be named the same.

Example: if you have ?par1?, ?par2? and ?par3?, rename them all as just ?par?. That way, only one prompt will show up.

[MFGF]

One other thing to beware of is that often, parameters for prompts against cube (OLAP) sources are based on returning a valid MUN (Member Unique Name), and these will be different for each different cube.  This may be why you currently have three separate parameters.

A neat option is to use an expression to build up the relevant MUN for each cube, hard-coding the initial part for each, and using a prompt macro for the final (common) part.  If this is what you find, we can help you to construct the relevant expressions.

Regards,

MF.

[dssd]

That leads me to another question. Say i build a cube and then a report out of it.
Then for some reason i build another cube with same number of dimensions, labels, data  and repoint the earlier report to come out of this new cube. The difference between the cubes is becasue of the type of database. Would it work? Would MUNs be different  and hinder this repointing to work

[MFGF]

It's pretty much guaranteed the MUNs would be different, so your report would break.

Regards,

MF.

[dssd]

Ah...even if everything the user sees is the same in the cube.  Order of the dimensions, number of dimensions, granuality, measures, etc. Only change would be the table/data source that would be used to fill the cube

What would be the reason for the difference in MUNs?

[MFGF]

If you select a member in the package tree and right-click then choose "Properties" you will see, among other things, the MUN of the member.  Notice how the MUN comprises the cube namespace, the dimension, the hierarchy, the level, then finally the unique path to locate the member.

Each different cube will have a different namespace (cube name), so the first part of the MUN will be different, unless you can find some way to name the cubes exactly the same.

Regards,

MF.

[dssd]

We plan to name the cube the same. Everything but the datasource would be the same. Also, these would be TM1 cubes. Does TM1 also have concept of MUNs?

[MFGF]

If your cube has the same name and the same structure, you will have the best chance of keeping the MUNs consistent.  Do remember that MUNs include the unique identifier of each member, though, so if you have a Product called "Soap" in one database with a key of "s1" and a Product called "Soap" in the other database with a key of "s01", they will most likely have different MUNs.

All OLAP sources (including TM1) utilise MUNs.  I guess all you can do is to try it and see how much success you have.

Regards,

MF.