Have you ever hit an error stating “Member ‘D-T-D’ in the Period Dimension has no Value for the Period Type Property”?
So have we. Due to the level of frustration in resolving it and the lack of documentation out there on the topic, we thought we’d take the time to do some testing and write up our findings.
With LCM, migrating dimensions is now easier than ever. However, in the early 11.1.2 versions, LCM had a bug when exporting Period type dimensions. This bug causes Dynamic Time Series members to be exported for Period dimensions that do not use it. LCM will also allow the import of these members, which cannot be removed once imported. This causes the application to be stuck in a state where it cannot deploy.
To circumvent the issue, follow the process below:
- Open the LCM folder at “D:\Oracle\Middleware\user_projects\epmsystem1\import_export\” (this path may differ depending on your specific installation)
- Locate the Period dimension file within the metadata backup in question, and open it for editing
- Delete the lines in the red box as shown in the image below within the !Members=Period section.
- The !Hierarchies=Period section also has a set of lines that will need to be deleted from the Period Dimension file as shown in the below image.
- Once both of these sections of Dynamic Time Series code have been deleted, the Period Dimension file can now be imported successfully through LCM.
NOTE: if the incorrect Period dimension file was import through LCM before it was fixed, it will be necessary to delete and recreate the Period dimension prior to re-importing.
Once the import process has been properly completed, the application should then deploy without the Dynamic Time Series errors.
We tested under a variety of circumstances and found that this “member d-t-d” error has in fact been resolved in the most recent releases: