topic Disadvantages when saving a program as a temporary local object in Application Development and Automation Discussions

Disadvantages when saving a program as a temporary local object

Former Member — Thu, 29 Mar 2007 10:40:23 GMT

Hi,

In SAP you can save your programs as a temporary object, i.e. the object is saved locally in a $TMP package without any transport request.

Can you see any disadvantages using these local objects? For example, is there any problems if two developers are modifying the same program: first one saves the program as a local, and the other one creates a new transport request at the same time?

Isn't that so that if you want to try something in an ABAP code, it is recommended that you first save the program as a local program (for example in a case you don't have any sandbox system)?

I myself cannot see any disadvantages using local programs - what is your experience?

Regards,

Jarmo Tuominen

Re: Disadvantages when saving a program as a temporary local object

Former Member — Thu, 29 Mar 2007 10:48:37 GMT

Hi,

I you want to transport the object form one server to another server then transprot required.If you have saved on local object then it is not possible to transport.

If you have saved in local object then it is easy to delete the program any body.

If you saved in transprot request then if you want to delete program for that also one transprot request is required.

Thanks,

shyla

Re: Disadvantages when saving a program as a temporary local object

Former Member — Thu, 29 Mar 2007 10:52:11 GMT

If you create an object as local object you can't transport it in the other systems (quality and production), this is the only disadvantage.

The same object (local or not local) can't be changed by differents developers in the same moment, because every object is locked while the developer is changing it.

Max

Re: Disadvantages when saving a program as a temporary local object

Former Member — Sat, 31 Mar 2007 05:33:49 GMT

I discussed with other ABAP developers, and theirs opinions are:

- For temporary programs or programs that are never intended to transport to other systems a local development class is ok.

- Local program is easy to delete when it is not needed anymore.

- Creating first dictionary tables, structures or data elements locally. Notice that they are ok but later forget to change object directory when using them in transportable programs. -> A short dump will occur in the next system.

- Creating function group locally and functions in there -> Later using functions in programs -> same problems as above.

- Local programs will be removed in system copy.

- It is not recommended to have local programs in a production support system because there is always a risk that these might effect on the testing of the support cases.

- In production support system it is a bad practice when two developers change the same object at the same time.

- You can always change the package, using transactions SE03, SE09, SE10, or using SE38 > Menu > Goto > Object directory entry > Change.

What are your own experiences of using local objects? Have you had any problems in a production support system when two developers change the same object at the same time?

Regards,

Jarmo Tuominen