topic Re: locking objects under same user ID in Application Development and Automation Discussions

locking objects under same user ID

Former Member — Thu, 15 Jan 2015 13:35:08 GMT

I have an user id in a SAP instance and i have prepared a report in that. The user ID is shared and I want to lock my report from others so that it does not get hampered. Is it possible?

Re: locking objects under same user ID

former_member201285 — Thu, 15 Jan 2015 14:03:53 GMT

I'm not really sure if I understood your requirement. If a lock has been set (by calling the respective enqueue function module), another user cannot get access on the object, even it is the same user id (say, we are talking about exclusive locks).

Re: locking objects under same user ID

Former Member — Fri, 16 Jan 2015 05:20:55 GMT

Hi,

If you dont want others to change your report/prg apart from the user id which you have used to develop that report, you can set editor lock so that other's cannot do any changes to that report.

Hope it helps you.

Thanks

Re: locking objects under same user ID

Former Member — Fri, 16 Jan 2015 05:51:30 GMT

Thank you Ulrich. Actually I was asking about locking The whole program so that it is uneditable to others who are using the same user ID as of mine. If someone logs in with the same user ID and Password they must not be authorised to edit my one. That was my question.

Re: locking objects under same user ID

singhmanishekhar — Fri, 16 Jan 2015 05:52:22 GMT

Hi,

There is no such type of tool or program that provides facility to lock or make report read only.

However, It is very easy to achieve this requirement. You should write a very simple program to update the "EDTFLAG" field of table "TADIR".

For locking, set 'X' in this field for field "OBJ_NAME" = your report name.

For unlocking, clear the flag.

Precaution :- As "TADIR" table contains information about all development objects. Use Update statement very carefully.

Thanks & regards,

Mani

Re: locking objects under same user ID

matt — Fri, 16 Jan 2015 06:03:14 GMT

Are you aware that sharing a userid for development is almost certainly a violation of your license agreement with SAP?

Re: locking objects under same user ID

matt — Fri, 16 Jan 2015 06:04:50 GMT

Be aware that setting editor lock is a disciplinary offence in many places.

Re: locking objects under same user ID

matt — Fri, 16 Jan 2015 06:05:24 GMT

Why do you write a program to do this, when it's an attribute of the program settable through SE38? Also be aware that setting editor lock is a disciplinary offence in many places.

Re: locking objects under same user ID

Former Member — Fri, 16 Jan 2015 07:01:55 GMT

Yes I am fully aware of that but for training purpose it may happen that your partner have the same ID.

Re: locking objects under same user ID

Former Member — Fri, 16 Jan 2015 09:17:14 GMT

.... and wouldn't solve this problem anyway as the users are sharing a single ID.

Re: locking objects under same user ID

Former Member — Fri, 16 Jan 2015 12:10:42 GMT

You can copy the code to local file or email draft (and delete the program) before leaving and paste it again when you come back next day. Other person can't hamper the program because it does not exist while you are away from keyboard.

Re: locking objects under same user ID

JL23 — Fri, 16 Jan 2015 12:37:22 GMT

I think this would not even be needed to download as you have versions management.

So the old version can be brought back the other day, and the same could be done from the second user for his version.

Re: locking objects under same user ID

matt — Fri, 16 Jan 2015 14:52:50 GMT

That's right. Just make a local Transport (or Transport of Copies) with the object on it, and release it.

Re: locking objects under same user ID

RaymondGiuseppi — Fri, 16 Jan 2015 15:05:14 GMT

Or use

Regards,
Raymond

Re: locking objects under same user ID

Former Member — Fri, 16 Jan 2015 15:18:56 GMT

You could transfer the program to one of the administrative users and then lock it. I can't guess how hard that would be to do, but I imagine it would be possible.

Neal