on 2019 Jun 11 5:25 PM
Our end users recently maintained the Entity dimension some days ago for the BPC Consolidation model. They tried to add 3 new members.
Now they cannot process the dimension.
On reviewing the BW infoobject I discovered that in the master data tables (/B28/Pxxx) there were entries for these new members, but when I looked at the text tables (/B28/Txxx) there were no entries. When I go into the "Maintain Master Data" option for the characteristic, the members exist, but there are no values for the 'language key' for these members, which is worrying.
No matter what I do in the EPM admin tool, I cannot process the dimension.
I reviewed the Note 1749556 but it says that the master data tables in this scenario don't contain entries for the added members, which is not true in our case (entries for the 3 companies were present), but it is the only note that addresses a similar problem (from what I can find.)
On looking at the Resolution in the note, I feel that I would not be able to add new members to the master data in RSA1 like step (1) in 1749556 because they already exist.
I know the precondition for this note is not the same as my situation, I still feel that it is similar-enough.
My idea is that instead of adding entries like Step (1), should I delete the members using the "Maintain Master Data" feature for the characteristic and then execute steps (2) to (6) in the note?
I am suggesting this approach because it would delete the 'corrupt' entries without a language key for the characteristic. Is this approach ok or should I try something else?
[SAP BW 7.3 SP5, Recently upgraded to CPMBPC 800 SP29 from SP9]
Request clarification before answering.
Thanks Vadim.
I managed to solve the problem using just the EPM tool (which is more preferable). I had to wait for the Controllers to finish with the productive system so that I could make changes, so I couldn't make any changes in production while people were running DM packages and also possibly entering master data.
The users told me that Company 6400 was the problem, but deleting this made no difference. It was only when I analysed the BW tables and found that for 6400 and 7900 there were no entries in the BW text table that I identified the erroneous records.
I went into the BPC Admin tool and deleted the two members and pressed <Save> then <Save and Process> and it worked!
Thank you for your analysis Vadim. I am speculating that saving multiple entries at once has caused the entries to be incompletely written to the database. I am wondering if the recent BPC upgrade may have made this more likely.
I now know how to find which entries are causing the problem in BW (missing text tables.) This may not occur in all cases but it was the problem in my case.
I thought that you might like this information in case other people have the same problem.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Would running UJA_REFRESH_DIM_CACHE in Production before deleting anything cause corruption (because of the strange entries in the tables for the 2 members)? That is the question.
(I cannot replicate entries with no language key in DEV or Quality so I cannot test it. The dimensions process normally in DEV and Quality)
I have already tested changing the ID of entries in 'Maintain Master Data' in DEV and Quality and this seems to be ok, but I want to try a less drastic approach.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I still haven't tried UJA_REFRESH_DIM_CACHE as things stand (without making any changes to the infoobject) for the production system. I was worried about maintaining the corrupt data in BW.
However, do you think that I should try running this program (before any changes are made in RSA1) and see if I can later change the text in EPM Admin for the two members (6400 and 7900) and see if it re-saves the text with a language key?
I can't recreate the problem in the DEV or Test system for this though.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
[9797 and 9798 were created in the DEV environment and not in the screenshot]
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I tried deleting a member in the test system and it said "No master data was deleted".
However, I then highlighted the member and it allowed me to change the ID from 9797 to 9798. It allowed me to save (and it activated automatically.)
I saw that there were two records in the text table in RSA1 (9797 and 9798.)
I went into the EPM Admin after running the UJA_REFRESH_DIM_CACHE and I could see two lines (9797 and 9798)
I deleted 9797 and did 'Save and Process' and it accepted it. I then went into the RSA1 text and Master data tables and only entries for 9798 exist.
So the strategy of changing the ID to a dummy value in 'Maintain Master data' seems to work
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You can try deleting member in test system!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Should I "Activate Master Data" on the Characteristic in RSA1 after making the changes?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Vadim. I will try it.
I will run UJA_REFRESH_DIM_CACHE after
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
And for there are no entries in the text table (/B28/Txxx) for these 2 members (you can see no entry in the 'Language key' and 'Long Description' columns) , but entries exist in the master data table(/B28/Pxxx), hence why we can see them in "Maintain Master Data" for the characteristic.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
[It is our productive system. Unfortunately, I can't seem to recreate the problem in the Development or Testing systems. This is making me more careful]
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
No, not yet. I am cautious about making the tables inconsistent.
However, I think that I could do the following:
1) Delete the 3 member with no language key using "Maintain Master Data"
2) Run UJA_REFRESH_DIM_CACHE for the entity dimension only (with only Re-generate Cache File ticked) .
3) Should I delete the 3 entries in EPM master data before step (1) to ensure consistency, or is it ok to leave them and do a "Save and Process" after step (2) to re-add them to the master data?
This is my proposed strategy. Can you see any problems with this approach?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Have you tested "Maintain Master Data"?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| User | Count |
|---|---|
| 9 | |
| 8 | |
| 7 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.