Question for Herren Jung and Heilman re SE11 vs SE16n DDIC Buffers

[Former Member]

In a dev logical system (XY1:nnn), I make a change to the domain and data element of a key field in a custom table.

The change is immediately seen in SE11 in client mmm of system XY1 (the dev test client), i.e. when rows of the table are displayed, the display header row picks up the new field label associated with the new data element that was assigned to the table column in client nnn.

But NOT so with the display in SE16n - the display header row shows NO literal for the redefined column

And more importantly, if I turn on editablity via &SAP_EDIT in SE16n, the column validation criteria are STILL those associated with the value range of the OLD domain, not the value range of the NEW domain that was just defined in client nnn and associated with the column via the new data element.

But if I wait overnight, SE16n in client mmm is now aware of all the changes in nnn, i.e. the field label display is correct for the column, and the column validation criteria are correct.

So - was gibt's, guys?

What is SE16n relying on that SE11 is not relying on?

And is this a bug in ECC 6, or a feature?

[clinton_jones2]

The table concerned has been designated as a table to be buffered for performance reasons and SE16n leverages buffered tables for performance reasons which SE11 doesn't? The 'overnight' may not be entirely correct, the same characteristics could be reflected in both SE11 and SE16n at any time depending on the buffering settings.

[Former Member]

The memory area of the buffering "rolls" every 40 minutes or so, so waiting overnight is not required either.

For "basis" folks there are some tricks to trigger the roll and sync the tables, but this is not normally a good idea in a production system.

Note that SE16N is an SAP_APPL component (controlling!) and the edit feature has been deactivated. SE11 is the basis DDIC transaction in the BC component, so it can trigger and access this change.

Well, David should report this as a bug to the controlling developers at SAP via service.sap.com...

Cheers,

Julius

[former_member181923]

Actually, I disagree Julius - I don't think it's a "bug" and that's why I didn't choose to report it via OSS.

I was merely interested in why SE11 and SE16n responded differently to the change in the other client.

I think your answer is quite edifying, and I therefore suggest you make sure to get that scarf from Marilyn.

[Former Member]

IMO SE16N is a great transaction, but it is in the wrong component.

Had it been in the correct component, it would certainly have enjoyed more support and not been a "hobby".

I would still class this as a bug though in SE16N. Particularly if the EDIT function while still around validates against the wrong domain...?

Cheers,

Julius

[former_member181923]

if the EDIT function while still around

Bite your tongue, JB!

Sssshhhhhhh!

Not all Basis teams have applied the patch that turns &SAP_EDIT off, and developers are lucky for the ones that haven't.

Best

djh

[Former Member]

When the patches go in, then try tcode UASE16N.

But ultimately it should be removed IMO or handed over to BC components (because that is what it is).

Cheers,

Julius

[clinton_jones2]

I would have thought the question is whether SE11 is considered differently from SE16n.

Surely when SE16n is considered, it leverages the buffered tables because it is considered that you would be man manipulating data, is that necessarily true with SE11 ?

[former_member181923]

Oooh - is that really true, JB?

Will &SAP_EDIT still work under UASE16n ?????

If so, then THANKS!!!!!!

Best

djh

[Former Member]

It will work for a while, but the patches for the edit are older than 90 days so the admin "grace period" is over.

On the other hand, hypothetically, such an edit function without bypassing the application buffer might be usefull if a program / DDIC error created erroneous application data. But it could still create far more complex problems in the database tables if they had been adjusted in Se11 / se14 already and where then edited. Deleting should be okay (bar some legal requirements... ).

I still think you should report the buffering though, because I like Se16N myself and had not noticed this.

Cheers,

Julius

[Former Member]

It does not bypass the buffering, lets you edit the data in the dynpro and then if you save (if authorized) it commits the changes to the database.

Hence the commit was removed because it is a SAP_APPL component but updates any DB table.

The field display in the selection screens are navigable. They should bypass the buffer IMO. Alternately they should perhaps not havr been buffered?

What do you think David?

Cheers,

Julius

[SuhaSaha]

> I still think you should report the buffering though, because I like Se16N myself and had not noticed this.

Actually i had noticed the same, but i had attributed this discrepancy to the ALV buffers

Anyway thanks for this fruitful discussion, learned something today! Do we have any notes highlighting this?

BR,

Suhas

[Former Member]

AFAIK there were requests to move it to BC components and then support it, but the SAP_APPL controllers declined...

So it was deactivated and support is probably limited to "hobby status".

The notes only correct the authority checks (also see [SAP Note 1434284|https://service.sap.com/sap/support/notes/1434284] !) and deactivating the editing function. With "package syntax checks" extended to runtime errors it would probably not have worked long term anyway...

IMO the SE16N should still be reported as an error and bypass the buffers when displaying the navigable (and editable...) ALV fields in the selection screens.

Cheers,

Julius

[Sandra_Rossi]

Hello,

In the discussion, are we talking about the Nametab buffer (refresh every 1 or 2 minutes on each AS via DDLOG)? (I'm not sure, because of the 40 minutes delay indicated by Julius (?))

I don't know how SE16N works, but, unless SE16N bypasses it explicitly, ALV usually uses the ALV buffer? (use program BALVBUFDEL to manually reset it) Or does SE16N has its own buffer?

Sandra

PS: I saw, thread is answered, but the answers surprised me

[SuhaSaha]

I don't know how SE16N works, but, unless SE16N bypasses it explicitly, ALV usually uses the ALV buffer? (use program BALVBUFDEL to manually reset it) Or does SE16N has its own buffer?

Hello Sandra,

Even i was confused about this

SE16N is a very useful tool for developers & equally dreadful one for auditors. May be the latter have convinced SAP not to promote SE16N in later releases

BR,

Suhas

[Former Member]

I think it will depend on how the buffer is managed (updated) and which memory area it is in.

In the case of the user buffer, it has a "flag table" which lets the memory roll (every 40 minutes) or the event of a logon (by the user) or a started new task (by the programmer) remove the flag again and reload the buffer for those key field values they were flagged for. You can set this flag using the ok-command RSET in SU01 or some obscure FMs can do it for individual users.

So my understanding here is that if you similarly invalidate the buffer in this case (e.g. using the report mentioned by Sandra) then when you next access the record then it will load the ALV buffer again and show the (hopefully correct) DDID value, or , after 40 minutes the memory will roll and update the buffers (also potentially some DDIC buffers used by SE16N?) and then things will be straightened out again...

... unless you made &SAP_EDIT changes in the meantime (or ill thought out ones at all) in which case all hell breaks loose...

I still think the problem is with how SE16N is reading the DDIC of the table. It should be moved to BC components and then bypass buffering IMO.

Cheers,

Julius

[former_member181923]

Hi Suhas -

If a site has a competent security/mgmt team, SE16n should pose NO problem to auditors, even with &SAP_EDIT left "on".

Allow it in DEV completely, allow it in QA with restrictions, and don't allow it in PROD at all.

What's the big deal?

Best

djh

[Former Member]

Hi DJH,

Completely agree with you, but a catch is that you must first try to request of the developers that they create views for the tables which are to be maintained despite the ability to use SE16N.

The downfall of SE16N was to hide the feature and initially make the authority-checks too weak such that seemingly harmless display access was sufficient to perform very powerful changes - bad move!

Cheers,

Julius

Edited by: Julius Bussche on Aug 31, 2011 3:34 PM

[SuhaSaha]

Allow it in DEV completely, allow it in QA with restrictions, and don't allow it in PROD at all.

You're the man, David !!

That's how it should be & that's how it was in my previous project

[Sandra_Rossi]

Hi Julius,

Thank you for your detailed answer. Unfortunately, I still don't understand

Isn't there a confusion here between the user buffer (tables USRBF* which contain aggregated authorizations, that can be reset by RSET, thanks I didn't know ), the user context (part of memory which stores authorizations), and the ALV buffer (in the shared buffer memory I think)?

Do you have any references so that I understand?

Thanks

Sandra