on ‎2010 Jun 29 2:44 PM
Hello Experts,
we want to change the SID-values of 0FISCYEAR.
Reason: data, that has been loade for e.g. 2010 is to be displayed as 2011 and so on.
That means, we want to give the entry of 0FISCYEAR for 2010 the SID for 2011 and so on.
(I know there are other possibilities, but we want do to it that way).
Now we found two possibilities for changing the SID (by switching to debugging ( /h ) mode in the display of the SID table):
1) change the SID to a value that has not been assigned yet (to not interfer with the unique index on the SID) and later change it back to the desired value
2) deactivate the unique index on the sid in TAC e.g. SE14 (and later activate it again) and change values
But both methods lead to errors in reporting. Messages are like "SID with value xxx cannot be found" (even though it´s there according to the SID-Table-Entries). So the reporting (queries) don´t work any more after changing the SIDs, even though the values in the dimension tables of the cubes haven´t changed.
Does anyone know the reason for this ? Or even better, has anyone a solution how to change SIDs so that afterwards the reporting still works ?
Thanks in advance,
Frank
Request clarification before answering.
Hello,
When we load master data system will create SID for reading purpose...because system will understand its own language better...
So it is creating a reference value for your master data.
If you change through SE11 debug mode...just the table entry will change not the reference and SAP wont advice this.
same case with SE14 also.
Why you want to assign SID of 2011 to 2010...its always better to reload the data when you have found some thing wrong in your data.
reload all 2010 data into 2011 and delete 2010 data.
of course its a tough job but you wont find any inconsistencies if you follow this.
Regards,
Pavan.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
We now found out: changing the SID-tables works - but only on the ABAP-Stack (that means queries executed with BexAnalyzer3.5, BexAnalyzer7.0 and in the ABAP Web (3.5)).
If a 7.0-Query is executed in Web 7.0, than the following error occurs:
Duplicate member created: 0FISCYEAR: K42010, Sids: 70002010 & 70002011
(we changed the SID for 0FISCYEAR K42010 to 70002011 (which was former the entry for K42011) and for K42011 to 70002010 (which was former the entry for K42010) - so now we e.g. can see the data for 2010 if we enter 2011).
So what I think is that somewhere in some buffer tables for the java stack, there must still be the old SID-Entry for K42011. Probably during the "normal" SID-finding-process (eg. loading data into a cube), these tables are also updated.
Does anyone know which tables have also to be updated if we change a SID so that this "trick" also works for Queries executed on the java stack ?
And, I appreciate your effort, but please no more "don´t do this, reload the data". I know that changing the SID is not a "clean" way to do this, but in this case we simply want to find out if and how it works.
Thanks,
Frank
SIDs are system generated values which you can not replicate... it is advisable to reload 2009 data as 2010, 2011 and so on...
you can make a self load on the data target!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| User | Count |
|---|---|
| 8 | |
| 5 | |
| 4 | |
| 4 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.