CODEWITHSUNDEEP
abaprelease-managementsap-basis
Skalozub
Skalozub

Reputation: 539

@Object already exported, no package change is possible" while mass package assignment

I need to change a package for ~250 SAP development objects (ABAP classes, data elements, tables, etc). I'm getting an error message TR242 (Object already exported, no package change is possible) when I'm trying to do the change via se24/se80 transactions or via RSWBO052 report.

SAP help docs say that the object must be copied under new name, the old one must be deleted and the new one must be renamed to the old name back. However, it's not a good way for 250 objects.

Is there any way to do a mass package change except call tranaction/LSMW for this case?

Upvotes: 3

Views: 2435

Answers (2)

Skalozub
Skalozub

Reputation: 539

The problem occurred because I was trying to move the development objects to a non transportable package as @vwegert metnioned above. The target package was marked as non transportable because it was marked as a legacy one. This happened because the target package was moved from a system with basis level lower then the current system basis level. Next steps are necessary to resolve the issue:

  1. The legacy package must be migrated via report RS_MIGRATE_PACKAGES (see note 1711900). The mark 'legacy package' will be removed, but the package will be still non transportable. However, you will be able to recreate the package after the migration.

  2. Delete the non transportable target package and create a new as copy of the non TMS package.

  3. Assign all necessary objects to package created at step 2 using RSWBO052 report.

Upvotes: 2

vwegert
vwegert

Reputation: 18483

This message occurs if you try to move objects from a transport-enabled package to a non-transportable package like $TMP. The rationale behind this is:

  • The object once was in a transportable package, so it must have been added to at least one transport request.
  • The transport request might have been transported to another system (directly or via ToC), so the other system might have that object.
  • The current system is the original system of the object, so it is responsible for notifying the other systems (via transport) when the object is to be deleted.
  • Moving the object to a non-transportable package is semantically equivalent to deleting it for the rest of the system landscape.
  • Since that process happens very infrequently, it's usually sufficient to direct the developer to copy and delete the object.

Upvotes: 0

Related Questions