Question:
Hi pals,
I've got a special scenario where I had projects in a format like nnn_A, nnn_B, and so on.
I needed to shorten this format into nnn_ instead.
I (with the appreciated help of the team I am in) changed everything that was needed, everywhere, in order to shorten this format. I reloaded the ods, cubes, attributes, etc etc
Now, in the master data of 0project, I've got projects nnn_A nnn_B ... and nnn_ living together;
as the nnn_A nnn_B are no longer used, I want to delete them from the master data.
As you know, you can only delete a record if it is no longer used anywhere ; I had to do some full reloads (activity, network, ...), I also had to manually ‘clean up’ some attributes (quick and very dirty solution) ;
But the system keep saying that my master data is used...
I found out something really strange :
For 0project CE004273.P.CE.60238__, for instance, there is still a CE004273.P.CE.60238__A that cannot be deleted.
I checked everywhere, and I don’t see CE004273.P.CE.60238__A being used anywhere (attributes, cubes, ods, aggregates, hierarchies).
But, I found out that the SID linked to that project is still used in cube T_CO
If I make a query on this cube, it never shows me CE004273.P.CE.60238__A, but it’s SID (323) is used in about 8 dimids, preventing me to delete the master data record. (*)
What I did to prove my findings :
I took the sid for CE004273.P.CE.60238__B (5472), (which was in the same situation as described above)
I searched for the dimids using this SID and I manually changed the field 5472 into 10583 (SID for CE004273.P.CE.60238__);
After that, as the SID for CE004273.P.CE.60238__B was no longer used, I have been able to delete the master data without further problem !!
Sooo, if we run a program on DIMID tables to change automatically all the SID’s like I did manually, it should work correctly afterwards.
Problem is that I am not 100% sure that this will not hurt the system...
If you have any good idea, or anybody that you can ask for help about this issue, it would be nice !
Ch
(by the way, I think I've tried all the different possibilities in RSRT, but none gave me any error (**))
(*) & (**)
I thought that RSRT would have told me that some dimids are no longer used, as it contains nnn_A that I can't see in my report, but oddly this dimid that should no longer be used is still linked to some figures...
PS : I am sure that if I delete the entire content of the cube saying "fact table and dimension table", the problem will be solved when reloading. The problem, of course, is that I really cannot do it.
Answer:
hmmm... your PS would have been my solution
Answer:
Can't you just reload into a copy of the Cube?
This way you can preserve all your queries, preserve reporting for the time being and once you're sure that everything is mirrorred correctly, delete the data in your original Cube and consequently delete the Master Data.
This would be a little more work then writing the program to modify you DIMtables, but it's definitely cleaner
Answer:
TFR: You are forgetting that reloading the data into another cube would still be using the master data.
_________________
Keep smiling
Answer:
TFR: You are forgetting that reloading the data into another cube would still be using the master data.
Hmmm, maybe my brain is still not recovered from being sick-as-hell all weekend, but this is what i think would happen :
if you reload from the Old to the New cube, the Dimensions of the New Cube will not contain the the "bad" SID's (since there is no fact lines related to it anymore).
If you then later on, delete the contents of old Cube, the "bad" SID's will also no longer be in the dimensions of the Old cube, so the you would be able to delete the Master Data.
If you then reload back from the New to the Old Cube, and entirely delete the New one, you're back on track...
SR, is there any flaw in my logic then?
Answer:
sounds pretty ok to me...
Answer:
TFR: You are forgetting that reloading the data into another cube would still be using the master data.
Hmmm, maybe my brain is still not recovered from being sick-as-hell all weekend, but this is what i think would happen :
if you reload from the Old to the New cube, the Dimensions of the New Cube will not contain the the "bad" SID's (since there is no fact lines related to it anymore).
If you then later on, delete the contents of old Cube, the "bad" SID's will also no longer be in the dimensions of the Old cube, so the you would be able to delete the Master Data.
If you then reload back from the New to the Old Cube, and entirely delete the New one, you're back on track...
SR, is there any flaw in my logic then?
Well, TFR,
this is exactly what I did...
And the problem I described for T_CO is in fact also occuring for ZT_CO_BU where BU stands for backup... ;-(
Answer:
We had a 4-day weekend ....
_________________
Keep smiling
Answer:
HI CHC,
Curious that your SID is the Dimid. Are you using it as a line item dimension? And if you run a query how are you not getting data since it is in the fact table (or did I read your post wrong)?
I am 99% sure that if you write an ABAP program to change those SIDs to their correct one it should not blow up your cubes. Although it is not my cube that is under the gun so its pretty easy for me to say.
On another note, if your DIMIDs are not line item dimensions then your ABAP program needs to get a little bit more complicated than just using the SIDs, you will need to find the DIMID with the right combination of SIDS 0project along with the other characteristics in the dimension.
Regards,
EL
Answer:
But, I found out that the SID linked to that project is still used in cube T_CO
EL, this should have been read this way :
"But, I found out that the SID linked to that project is still used in one of the dimension of my cube T_CO."
I know the complexity of the abap, however I really can deal with it, no problem.
The remaining 1% is the same as mine, but as you stated... it is MY cube that is under the gun... and as I am working in a very sensitive context, I can't even have 0.01% chance to make something wrong, so better think twice.
HOWEVER,
I found that if you work relaxed on a thursday, with the help of a colleague being able to see the problem from another point of view, it's always better than to work alone on a slow remote connection from home on sunday afternoon (was rainy anyway, but still...)
And I found out (I'd rather say that HE found out, 'cause he's probably reading this) that in fact I am a stupid moron, and my query was showing me the text instead of the code, meaning I saw CE004273.P.CE.60238__, but in fact the key for this was CE004273.P.CE.60238__A and another CE004273.P.CE.60238__B, so in fact my SID were actually used...
I even did not notice that I had two lines with the same CE004273.P.CE.60238__, what should have pointed me in the right direction.
So, I corrected this b** update rule that was not working as expected, and currently busy reloading everything from the backup cube to the basic cube. Should be ok soon.
Ch
( )
Answer:
Hi
CHC
so u mean SR's solutions worked for u??
i still dont get these
if you reload from the Old to the New cube, the Dimensions of the New Cube will not contain the the "bad" SID's (since there is no fact lines related to it anymore).
If you then later on, delete the contents of old Cube, the "bad" SID's will also no longer be in the dimensions of the Old cube, so the you would be able to delete the Master Data.
above u can delete OLD cubes contents yes for removing BAD SIDS.
but how can u delete Master Data when u have NEW CUBE(Back up cubbe) still having the data.
Answer:
Hi Guest,
read the original post again... the master data CHC wants to delete is no longer used anymore.
cheers,
El Belgio
Answer:
I re-read the whole thread and for once I don't see any solution proposed by SR ?
For our education :
because of my mistake, I though that there were remaining dimids not used;
so I assumed that deleting a request in the manage tab of an infocube was not deleting the related dimids, which is false.
I did about 25 different tests, loads, delete, programs around that,
and in fact if you delete the requid from the cube, and reload it after having change the update rules (creating new dimids), the system will take care about deleting unused dimids.
By the way, none of my RSRT tests gave me any errors, what I found strange, but was correct as my understanding of the problem was false.
This is at least in version 30b sp 19.
Cj