Forum Discussion
While on a roll with DynamicDimensionService issues, here is another.
All the Member functions in which you pass-in a DimTypeId fail when called from within a DynamicDimensionService file, if the DimTypeId matches that of the dynamic dimension currently being rebuilt.
These functions all fail when they check the Dynamic Dim currently being (re)built, as I guess internally OS has not properly initialized the dimension until it receives the dynamic members and relationships you are about to (re)assign to the dimension.
The workaround I've found is to use the variant of GetMemberInfo() that accepts a pass-in DimPk, so that you can pass-in the Inherited DimPk, and thus avoid having the OS Member function look at dynamic dimension you are in the process of (re)building. The Member expansion functions all work, as they also require a DimPk rather than DimTypeId.
- JackLacava11 days agoCommunity Manager
Could you provide a sample? Because i've just tried with a simple GetMember and it works fine in 9.0. Likely it won't work if you're trying to look up a member of the dimension itself (because you've not finished building it, of course), but should work fine with other ones of the same dimension type.
- rhankey11 days agoContributor II
If my prior response was not clear, I apologize. GetMemberId(), GetMemberName() etc that ask for DimTypeId work fine on other DimTypes, but fail if used to find a member on the DimType of the Dynamic Dimension being built. The error message indicates it has issues with the Dyn Dim that is currently being built. IMHO, these functions should be smart enough to skip over the dynamic dim that is in currently being rebuilt. The use case is when you need to find MemberId's of specific inherited members to which you want to dynamic children.
The workaround is to use the GetMemberInfo() variant that accepts DimPk, which if set to the InheritedDimPk then works. All the other Member functions that take DimPk work fine.
Related Content
- 8 months ago
- 2 years ago
- 2 years ago