Change access in SE16

[Former Member]

Hi

I have a certain role assigned to a user in the D system which gives change access to a table (SE16). However the same role when moved to P system has some issues. The change access has disappeared. When I go to SE16 to make some changes to the table I see that the user can only display.

Any ideas on this will be greatly appreciated.

ravi

[Former Member]

What version are you on?

What are the client settings in D and P (via SCC4)?

Why have you not assigned a view of the table to a transaction and let the user maintain it through there instead of potentially giving them access to lots of tables?

[Former Member]

Hi

Version: 4.6c

in D scc4 shows the following

Changes to repository and cross client customizing allowed.

Protection Level 1. No overwriting

eCATT and CATT allowed

I dont have access to SCC4 in P

The reason why a transaction was not created for this is because this is for a super user (Fire fighter). Firefighters are meant to have this kind of access.

ravi

[Former Member]

Hi Ravi,

Firstly a firefighter would usually use SM30 to do this, not SE16.

Off the top of my head sounds like the client settings in P are stopping the table from being edited.

[Former Member]

As Alex already indicated giving SM30 Which is also not preferable, but always better than SE16 to use for direct table changes, will have the same problem as it will probably be the client setting that forbids this.

As it is a firefighter userid, and if you have a strickt procedure for acces to that uid, why not give SAP_ALL, as discussed a lot of times before on this forum under verry stricet procedures it can eb allowed to give temporary access to a uid with SAP_ALL.

Besides you will probably also have to change client settings so you need a strickt rrocedure for that also!!

[Former Member]

If it's a custom table then maybe the delivery class can be changed to C - that should allow it to be maint in a locked environment if memory serves me correctly.

[Former Member]

Alex

although technically right i would suggest to be verry carefull with this and would suggest to investigate:

A is there no other way to change the data, f.e. a normal TRX

B is there no way to transport the data from DEV to PRD.

Because when the table is set not to be changable in a PRD environment there must be a reason which should be important.

[Former Member]

as the 'old' basis guy, may i suggest to refrain from authorizing SE16(N) at all (at least not so widely spread). this may turn out to be a real performance-killer as users always try to Excel-Download the biggest tables available (BSEG, ESSL, MSEG ... you name them)

use SM30 for customizing tables if in need, better still: create a maintenance-view with its own transaction attached for the tables that need viewing (or maintenance).

for database-tables authorize SQVI if in need or SQ01 and make sure you teach your users well. both tx. have the (assuredly small) advantage that there's coding generated that will take to existing indices (if available). one cannot say that of SE16.

for all others goes what Auke says. do not attempt to change data on db-tables manually, except your are VERY sure of what you are doing. i haven't seen a lot of that though.

[Former Member]

Auke - I agree with everything you are saying, I was just thinking through the ways this could be achieved.

Transaction linked to a view of the table is by far my favourite, but as the saying goes there is more than one way to skin a cat.

If it is a custom table then the chances are that the developer didn't think too much when they created it. I would be very reluctant to do this for an SAP delivered table outside of responding to an OSS note.