Transaction STDR allows to delete TADIR (obj. catalog) entries without object. The problem is that this check is only as good as the CHECK_EXIST
function for the object. If the CHECK_EXIST does not find all objects, there will be incorrect inconsistencies. Therefore I would be careful to delete all TADIR entries without object. This was the reason, why it is now possible to delete the entries separately, if you display the results. I would recommend to only delete customer objects if called for.
- If you have deleted an object, the TADIR entry still exists until the transport is released. In this case STDR could delete the TADIR entry before the transport is released. In this case there will be an error message during release of the transport. But (with the needed authorization) the user can go forward and release the request despite this error message.
- Unfortunately you cannot avoid the inconsistencies and not all inconsistencies shown by STDR are real inconsistencies. Object catalog entries without objects are created by several applications, which do not delete the objects completely.
- The problem is: If R3trans finds a single table entry of an object, the TADIR entry is not deleted. For the application the object is deleted, if the entry in the main or primary table is deleted, because only this is checked. But R3trans is checking everything and if there is a small rest of the object, R3trans will transport this and will not remove the TADIR entry.
Only the TADIR entries of local objects are deleted together with the object. The TADIR entry of a transportable object is deleted during export. R3trans searches in all relevant tables for entries of the object and if there is nothing a deletion is transported and the TADIR entry is deleted by R3trans. The delete-flag in E071-OBJFUNC is not relevant. Only for tables the delete-flag is important (I think only to be sure that the table should really be deleted), but for all other objects the delete-flag is reset by R3trans. This is the reason, why you get an error, if you take over an already imported piece list with deletions. In this case the TADIR entry of the deleted objects was removed during import. And if you export the piece list now, you get an error message that the TADIR entry of these objects is missing.
For example the class builder (SE24) does not delete a class completely sometimes and then the TADIR entry of a deleted class will remain.
- A lot of inconsistencies of type 'objects without catalog entries' are no real inconsistencies.
For example STDR checks all includes and searches for the related TADIR entries like R3TR PROG or R3TR CLAS. But some includes are
generated by ENHO or TTYP objects. Unfortunately STDR is not checking these entries.
Therefore a lot of 'objects without catalog entry' have a catalog entry, especially objects like R3TR PROG <name>======E, because the TADIR
entry of such a program is R3TR ENHO <name>======E!