Hi Team,
I have a question around the orphan members. I know that when we remove the relationship, the member gets moved under the Orphan section. After moving to the Orphan section, can we load data into the member through the Workflows?
Thanks in advance
AK
No. If a member is orphaned, it doesn't belong to the dimension anymore, so it cannot be seen by anything. You will get an error like this when you try to load:
OneStream EmployeeNo. If a member is orphaned, it doesn't belong to the dimension anymore, so it cannot be seen by anything. You will get an error like this when you try to load:
Can you move an orphan account back into the hierarchy? If so, how?
OneStream EmployeeAdd a Relationship
The Child Member will be your orphaned one (which will still be listed in the Dimension where it was created).
We can see that orphan members show up in System Diagnostics Application Metrics. Does this mean that data record in Orphan account or flow members that have data in them count towards the number of records in the data unit?
Yes. Orphaned members can still contain stored values in the cube, and they are included in the data unit.
The previous response is not technically correct. An orphaned member still belongs to the dimension in which it was created. It is orphaned when it is no longer attached to any hierarchies within that dimension - as in, it has no parents.
That makes sense and explanins a few things that we were trying to understand. It would be nice if we could easially clear data from orphan members.... I'll add an enhancement request.
I have built functions to clear out data for specific members or intersections, be it orphaned or otherwise, from the cubes, stage and journal tables, but I keep such tools well away from virtually all hands. It's a really quick way to make a really big mess, if for example the orphaned member was accidentally orphaned, holds one side of a balanced transaction, or someone spent a lot of hours entering the data in via a Form.
I usually let orphaned members sit awhile, in the event they were orphaned in error and to see how much stored data will 'move' out of the member. I'll periodically run a DeleteOrphans utility to get rid of orphaned members containing no data from some or all dims. For orphans still containing data, I want to know from where the data came, so decisions can be made as to whether Stage data needs to be retransformed/loaded, Journals need to be unposted/modified/reposted, Forms data needs to be amended. There could even be annotation data to consider. If it still contains calculated data, I may need to be looking for logic that needs to be modified if the data didn't clear after reconsolidating. I think you might get a sense why OS might have some hesitation in building a tool that can easily clear data from orphaned members, and why I keep such tools I've built under lock and key.
