Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Changes to DDIC not reflected in SE16N

Former Member
0 Kudos

Hi gurus,

We have a weird issue in our QA system: following a change to a 'Z' data element (we change it from a CHAR(2) to a CHAR(4) and we change the text) used in some 'Z' tables, we are not able to fill in the data in the table via SE16N, because the changes are not reflected. The field name is still the same and the field lenght too, though we change it from 2 characters to 4 characters.

This issue is only happening in our QA system, when it was moved in production, everything went fine.

Does anyone have an idea ? Is there some kind of cache/buffer used by SE16N that should be rebuild or refreshed ?

Thanks in advance for your help.

Greg.

1 ACCEPTED SOLUTION

RichHeilman
Developer Advocate
Developer Advocate
0 Kudos

Weird. Do an 'activate and adjust" on the table via SE14. Make sure to select the radiobutton to "save data".

Regards,

Rich Heilman

6 REPLIES 6

RichHeilman
Developer Advocate
Developer Advocate
0 Kudos

Weird. Do an 'activate and adjust" on the table via SE14. Make sure to select the radiobutton to "save data".

Regards,

Rich Heilman

Well, it is far more stupid than that. I needed us /$SYNC in the ok code to reset all application server buffer, and then SE16N was normal...

Here's a page to a summary of all ok codes: http://abap4.tripod.com/OK_Code_Values.html

Submit report BALVBUFDEL for clear ALV buffer, for all system.

0 Kudos

fixed my problem, thanks!

0 Kudos

Thanks this worked for me as well, database utility also failed but this worked

Gideon_PW
Explorer
0 Kudos

I think /$SYNC its work for me.. and this solution is perfect to my issue