The structure components were overlapping.

[hagit]

Hello Expert,

In CI_PRPS I have a ZZ field with data element Z (CHAR 3)

1. I changed it to GM_SPONSORED_PROG (char 20)

2. I activated CI_PRPS successfully.

3. I changed it to GRPNAME (char 15)

4. I activated CI_PRPS and it became partly active

5. I looked in SE14 and notice that the problem was 'time out'

6. In SE14 I click on 'background ' and then on 'continue adjustment' (see capture1)

1. A job was running (capture 2)

1. When the job finished, I activated CI_PRPS in batch. Then CI_PRPS and PRPS were activated successfully.

2. I transport the above to QA and production. In SE11 I saw that CI_PRPS and PRPS are activated successfully.

1. In production a user run GR55 and received a dump.(capture 3 & 4).

1. In the debugger I see that the type of T_PRPS is PRPS. (capture 5)

1. It seems that the DUMP is connected to the above change. Is it? How can I solve it?

Thank you

Hagit

[aoyang]

Hi, in your production system, go to SE11->PRPS->Utilities->Database objects->Check. Is there any inconsistency? The same way, check object CI_PRPS as well.

[hagit]

aocheng Thank you for your replay.

For PRPS :

Database object for PRPS is consistent

For CI_PRPS I did not find ' Database objects' under Utilities. But when I click on the check icon ,it displays 'No inconsistencies found'

[aoyang]

hagit Can you check PRPS at the runtime as well? Utilities-Runtime objects->Check, and Utilities-Runtime objects->Recursive check. According to these notes, the dump looks like it's still caused by DDIC object inconsistency.

https://launchpad.support.sap.com/#/notes/2153862

https://launchpad.support.sap.com/#/notes/2554446

Even if the result of the check is no error and consistent, I would suggest you still try to activate PRPS and CI_PRPS again in production and QA system.

[Sandra_Rossi]

If you do database adjustment while people are connected or programs are running, it's the kind of thing which happens. Don't adjust database while system is open, to avoid number of short dumps. simply ask the user to do GR55 again.

[hagit]

aocheng ,

Thank you so much for your help .

I activated CI_PRPS in production and it solved the problem.

Hagit

[hagit]

sandra.rossi Thank you for your replay.

It's good to know that data should not be adjusted in working hours.

Hagit

[aoyang]

hagit Forgot to mention that you adjustment in production should be done in the non-operating hours, but glad to know activation of CI_PRPS did not take long and it resolved the issue!

Converted my comment to answer.

[Sandra_Rossi]

Note that you should have informed by the administrators that the import of the transport request containing the table adjustment resulted into an error too...

[Sandra_Rossi]

EDIT: Note that you should have been informed by the administrators that the import of the transport request containing the table adjustment resulted into an error too...