TM1 Forum

The report doesn't even have to be zero-suppressed. For a number of years now the default behaviour for TM1 as a data source for Cognos BI has been to do server-side zero suppression. Which means that if your cube is not fed correctly you will see no data in Cognos. Server-side zero suppression can ...

Subsets do not store any relationships between elements, so unless your subset is designed to encode relationships in the element order itself (e.g. the parent you're after is always directly before the child or something similar) then you're out of luck. Of course, ELPAR can be used to get any pare...

Do you have the Package Connector installed on the machine where you are running Architect (as well as on the server)?

TM1 has a built-in mechanism to loop through the source data twice already - that's what the Metadata and Data tabs are for. And you can manipulate data on the Metadata tab - there are no rules against that. Having said that, why can't you execute the condition separately for each record? I can't th...

cTempViewTo is a target view.can i send the code written in TI Process. While normally posting your actual code is highly encouraged (ideally in the first post of the thread), it looks to me like in this case we have painstakingly amassed enough information to conclude that you need to include rule...

I will ask again, because it seems very important here:

Is cTempViewTo your source view?

The name suggests that this is your target (ZeroOut) view, not the source. That would explain why the ViewExtractSkip functions are not having the expected result.

Is cTempViewTo your source view? Also, typically you would not want to include consolidations or zero values because the view can become very large and usually there is no point in copying such values. Or even a place to store them. Are you perhaps trying to copy some C-level rule-calculated values?

Steve is right. Cognos BI needs a single, unique hierarchy path to each element. If there is more than one, because e.g. there are alternate hierarchies, it will use the full path to identify an element. And what is more, from Cognos's perspective each one of the instances of that element in the hie...

Hi Rajesh. The Cube View you are using as the data source for your TI needs to include rule-calculated cells. By default such cells are excluded, just as consolidations and zero values are. You can use the TI function ViewExtractSkipRuleValuesSet to set the flag appropriately.

When you say your version dim is a 'control' dim do you simply mean its name is prefixed with the '}' character or do you mean it's actually one of TM1's pre-existing control dimensions? How is this dimension updated? I would assume it's updated via TI? Are you by any chance using DIrect functions t...

Kamil, Interesting suggestion. I expect the people who wrote the license agreement will have no idea about a "Local server" and I can find no specific referenc to it in the 10.2.2 licence agreement. However, if it is running on the administrator's local PC (not the server) and the instanc...

A good (albeit a little old-school) option for that sort of single-user payroll cube is the Local Server you can run from Architect/Perspectives ('Start Local Server'). The Modeller licence (which that person needs anyway) covers that type of usage already if memory serves me well.

I've seen that error after moving to 10.2.2 FP7, but could get rid of the message by adding "DimensionUpdateDirect(DimName)" at the end of the Epilog of each process handling with direct dim updates. Weird. I always do the DImensionUpdateDirect in Epilog after any Direct inserts, mostly b...

What version did you see it in? I have started seeing this message after upgrading our on-premise 10.2.2 from build 10.2.20300.98 to build 10.2.20700.43. It happens at the end of any process that makes use of the Direct metadata functions, but seems to have no impact on the completion status of the ...

While all the usual access-related caveats apply, it is quite easy to give a user access to edit rules for just a single, specific cube. Instead of assigning the user to the built-in ADMIN group (or, a slightly safer option, DataAdmin) you can assign the user to a group who has admin-level cube secu...

Alan's solution will work, but if you are authenticating via BI, it is possible for the deleted clients to "come back" so to speak, simply by logging back into the TM1 service. Provided they have the credentials (AD, for example) of course. This behaviour can be easily prevented by using ...

Have you considered my suggestion from the linked thread to have the attribute values rule-derived, using the TM1USER function as a dynamic variable helping you to decide who should see what? Edit: here's a rule sample to demonstrate what I mean. [}ElementAttributes_MyDim:'My Alias'] = S: IF( DB( '}...

I'm afraid you cannot hide aliases using element security, but this thread might give you some other ideas to explore.

Setting the weightings of ElmName against all its ancestors to 0, would prevent the consolidation of ElmName in all dimensions. Not exactly. Strictly speaking ElmName only exists in one dimension (Dim1) and consolidates within that dimension. But nevermind that, I think I know what you mean now. I ...

RonLat wrote:Can the consolidation for ‘ElmName’ can be disabled only for one particular dimension, so that it consolidates normally in other dimensions of a cube?

I don't see why not. Just set the weightings of ElmName against all its ancestors in that dimension to 0.