Skip to Content

Unreleasing a transport request and modifying table content in debug mode #sapadmin

16/09/2013: As mentioned by Julius in the comments, this blog post (orig 2011) is kinda silly 🙂 . The reason mentioned below is not a valid reason to “unrelease a transport request”. The blog post does demonstrate how system administrators can get creative in order to change something to their benefit or in order to fix a “stuck” situation. I’m planning on writing a follow-up blog post on the topic / comments in general. You basically shouldn’t take this kind of action without a valid reason and I cannot come up with a situation directly where you have a valid reason.

CAUTION: Note that unreleasing a \ transport request  is not recommended \ unless you have sufficient knowledge on TMS.

CAUTION: Note that editing table content \ can be dangerous and you can mess up your system if you start editing tables \ without enough knowledge and insight on the table content and table \ relationships.

A possible use case is a situation where a transport request \ release was started where the transport content is by mistake incorrect. For \ example someone wanted to export a table definition but gave in the wrong ABAP \ dictionary element and ends up exporting the table content instead. Exporting \ table content of large tables takes time and creates large transport requests. \ The user notices that the release of the transport request takes abnormally \ long and notifies a #sapadmin to check out the situation.

After the situation is explained the #sapadmin is aware of \ the mistake of the user and action has to be taken. The export of the table \ content can be cancelled by killing the process on OS level. This will cancel \ the transport release and the transport release will be in status cancelled.  Now let’s take a look how you can unreleased \ that transport request so the content can be corrected.


List table E070 in transaction SE16 (press F7 after filling in the table name)


Fill in the transport request (notice <SID> is hidden here because of sensitive content) – if SID = AA1 request here would be AA1K900625.Press execute


Double-click the TRKORR value entry


You can now see the entry for your transport request in table E070

Now you have some options but in the end you have to change the value of field TRSTATUS to set the transport request in an unreleased status.


Enter /h and press enter twice in the command line to go into the coding in debug mode


Scroll down in the code until you reach the code = ’SHOW’ line(notice the other available CODE values: EDIT,INSR,ANVO (edit including keys) an DELE)

Double-click code in the program code


This will add variable CODE into the right pane of your debug window

Click on the pencil to the right to change the value of Variable CODE


Change the value into EDIT and press the enter key

Press F8 once done


Change the TRSTATUS field value (press F4 for input help while the cursor is in the field)


End-result my transport request is modifiable again

You can then either add the missing entries, change an incorrect entry or delete the transport request all together.

You must be Logged on to comment or reply to a post.
  • Tom, id this necessary? Cant we simply abandon the transport and create a new one than to modify standard table content and mess with the integrity of data?
  • I think SCN moderators should not have allowed this blog to publish. Every ABAP program knows how to change the table content directly in debugging mode (assuming he/she is authorized to change the field content in debugging mode) but it might be highly dangerous when people with limited SAP knowledge start doing it. It is like teaching the people how to hack the network.
    • Yes, but maybe there are some security people out there that didn’t know about the security risk this could be.   If one person knows how to go around the system.  Several more of them know as well.

    • Hello Sharad

      To start with thanks for vocing your opinion.

      These kind of discussion around which content is a bridge too far are important.

      I agree with a lot Michelle sais and she puts everything in perspective.

      The SCN moderators don’t immediately moderate this blog. They will assign points (maybe not much) to the blog and when that happens it means a moderator has read this blog. They can still decide to take it off but in my opinion that isn’t necessary either.

      At some point in your career you have a switch from junior to senior or whatever and if you never do any action that could possibly harm your SAP system then it’s going to take a long time before that switch takes place.

      This is a matter of responsibilities, taking responsibility and of course security. Security should be able to capture these kind of actions and question the person who is editing table content in debug mode why that was necessary. That person should then be able to refer to the correct change request for example which can justify the action(s) taken.

      You can hardly call the actions in the blog “hacking”. Almost all #sapadmin have access to the back-end server and to the database. They can change table content through SQL statements as well.

      Another argument is this one. As an ABAP programmer you can easily write a SQL statement that deletes table content which can be dangerous. Does that mean it’s not allowed to blog about how a delete statement is programmed?

      If I had know-how of an actual dangerous security gap that was not yet discovered I would not post it in a blog. I would send the necessary information to SAP. It’s not my intention to harm SAP.

      I hope this gives you a view on my side. As I said in the beginning these kind of discussions are important so thank you for your comment.

      Kind regards


      • Really liked this: “As an ABAP programmer you can easily write a SQL statement that deletes table content which can be dangerous. Does that mean it’s not allowed to blog about how a delete statement is programmed?”

        Totally agree with you!

      • Security through obscurity is no security at all, so I don’t have a problem with any techniques being published.

        However, the process described here is in my view entirely unnecessary, as you can always fix things by creating a new transport. I’ve been doing SAP since 30D and have never come across anything that could only have been solved by this procedure.

        • More useful would be a blog about the object types which record generated versions into the data files at the time of recording the changes into the task, and not when releasing it. One of them is ACGR as an example. Lets see who knows all the others for which this debugging of keys will create inconsistencies?



  • Hi Tom,
    You can achieve the same thing, using a standard SAP program called RDDIT076.
    It works as a charm and the chance you make a mistake is smaller 😉


    • Hey Johnny 🙂

      Thanks for the tip and adding value to the blog.

      I don’t recall having used this program so definitely a good comment. I’m learning something here as well which is great.

      The program requires less steps to perform and it doesn’t push information into the system log either I assume.

      Kind regards


    • YES!  Learned something new.  That means I get to go home.  Oh yeah that’s right, I’m trying to get caught up prior to Teched!

      Counting down to LV – 2 days until Innojam!  I don’t count today!

      Thanks for the additional tip!


    • Thank you for this! I didn’t know about this report.

      It’s amazing how you still can find standard reports that do lots of things, even after years and years working with SAP!

  • Here are a few suggestions:

    1) How to create a supplier and send an EDI payment to them in debug mode.
    2) How to use debug mode to change your base salary in the HR module.


    • Hello Joe

      Thanks for the suggestions although I wouldn’t hope to see any of those appear if I were you.

      I can give you something to think about, how many persons do you think have checked your salary in HR?

      I didn’t blog this without reason. The reason is definitely not to create a fuzz but apparently the content does that.

      I think it’s great that community members react to a blog, whether or not there reaction is positive or not it shows they care about the community and I can tell you SCN is very nice community.

      This blog doesn’t feature a security gap. The content features merely a few “simple” tricks. The security audit should capture these kind of events so I don’t see why this blog would not provide valuable content.

      To be able to secure a SAP system you have to know all of the tricks first.

      Judging from Johnny’s comment there is even a program available to unrelease a transport request. I don’t recall using that program so I actually learn something here as well which is exactly the point.

      I share knowledge and get knowledge sharing in return as well which is great.

      Kind regards


    • Hi Joseph,

      Doing either of those things would be fine, as long as it is in a test or development system. If use of the debugger is normally allowed in a production system, then all is lost.


    • A careful de-activation of SAP_EDIT or the use of Virsa should allow you to control the usage of firefighter users, thus preventing anyone to mess around with that kind of security breaches.

      Now, this is anyway supposed to happen in a development environment (I hope), and as I mentioned (joking) in a Twitter comment to the blog: this is a wreckage of all the best practices.

      But I clearly understand this is to use in situations where no other alternative exists. But even then, there is always a different alternative, I have just educated the users on my previous project to use them, and thoroughly teached them that no other tech alternative exists (I lied, I know). I just hope they do not read that blog, and find out 🙂

  • I don’t understand why the others are worried about the content of the blog.
    There is nothing in there which you could not find using google and your brain.
    SAP users who don’t know what they are doing should simple don’t have the needed user rights.
    That is the job of a good administrator.

    I definetly like the step by step guide.
    Good work in my opinion.

  • Tom,

    This is a great blog, which shows an important tool within the SAP Consultant’s bag of tricks.
    These types of ‘work arounds’ are not day to day activities, they are for when your back is against the wall and you must get it working. I understand that we all know people that we would never give this information to, but these people must realise that if they use this information and it goes wrong then they will be held accountable.
    As a technical consultant, I am often entrusted with unrestricted access to data at the application and the database layer, does that mean I defraud customers/friends by stealing information/money – No it does not.
    My own opinion on this is that this information is out there in various guises anyway, and anyone who is dangerous enough not be trusted with this is unlikely to take the time to find it anyway!
    This blog and the discussion is has prompted is healthy and the essence of what SCN is and should always aspire to be.

    • Chris

      Thanks for your comment and your support

      #sapadmin indeed often have access to sensitive information and have the responsibility to not steal the information and not mesh up the information either.

      Discussion about what is or is not blogable is good and should take place within the community.

      Kind regards


    • Hello Gregory

      I agree that the tips/tricks are not meant for daily use. It’s meant for exceptional situations.

      Kind regards


  • I guess RDDIT076 seems to be a great approach. But it is limited. We will have to use methods like what is proposed here or even write update programs in dire situations to update E070/71.

    I often have to update a transport after it is released, especially its attributes like project, description etc. In such cases we should probably use this.

    But now that this blog has taken the attention on everyone who cares, I have a question for y’all.

    What happens if we unrelease a transport and then release it again? what if the transport was migrated to QA or Prd already? What is the impact?

    Secondly, is there a way in TMS/CTS to mark a transport as abandoned?

    • Hello Salai

      I haven’t tested out your suggestion yet to release a transport request and have it imported in QAS and then unrelease your transport request in DEV.

      Unreleasing it using the above method will be possible. I don’t know if releasing it again will be possible if the data-and cofile already exist in your TRANS_DIR.

      If you would delete the data-and cofile than you would probably be able to fool the system and in that case I assume the release will be possible again. After that happens the transport would be added to the queue of QAS again. What you then import in QAS would equal what you have in DEV because he always takes the content according to the data -and cofile.

      Hope this makes sense for you. I wouldn’t recommend that kind of action at all though. You would be better of to create a correction in development and import that correction right after the faulty transport that is already migrated to correct the situation.

      You can deny a transport in a approval queue but it’s not really the same as “abandoned”. The mechanism isn’t “great” either. You could still add the transport request manually to an import queue.

      Kind regards


      • Oh no. There is no ways I’m going to try that. But I wanted to understand the impact.

        I was just trying to find a way to flag a transport as “abandoned” so that noone would import it by mistake. I dont have an option of correcting it with another transport since the changes are not reversible.

      • Re-releasing the transport overwrites the existing data- and co-file.

        The disadvantage of this is the ‘new’ transport does not follow the approval flow anymore, if it is in use.

        And reimporting it in a system is the same procedure as reimporting another transport more than once.

  • This mode actually ends up in the SE16 edit option for the debugger which is protected by the strictest authority-check the system can make (which everyone should know and respect that they dont have access to 😉 but I still do not see the necessity of hobbling over the TMS and table content in the debugger?

    If you transport as packages then release the bugger and transport the package again (just get the sequence right ;-).


    • BTW: SAP seems to class these sorts of edits as security breaches according to SAP Note 1304803 – which removed some similar reports and applied proper checks / validations  to others.


  • hi Tom,

    Thanks for sharing, we’ve learned 2new tricks in this blog. As for as i know, experienced or average sapadmin should know how to go into debug mode, but this doesn’t mean they’ve breached of security by doing this, most importantly, they will not do this without being push to the wall.

    SDN is a place for sharing, and definitely you did the right and good job always.

    Nicholas Chang

      • Is re-releasing this blog by necro-posting it not also such a low-brainer as the excited newbie, or do semi-experts not adhere to their own words of caution?

        This whole blog is very silly. Just encourages stupid things.

        • Hi Julius

          As far as I’m aware I didn’t republish or otherwise I didn’t mark the “minor update” checkbox which should in my opinion be checked by default.

          I cannot honestly say that I think that ‘unreleasing a transport request’ is a good idea. It’s not and there are much better alternatives available to date.

          To some degree, looking back on this “old” blog post, it is kinda silly.

          Best regards


  • I should be bookmarking this!

    A day will come where the purpose shall be met by this wonderful tip, however with safety jacket on.

    Who said, that once the transport is released can’t be modified ? It can be, and I am going to tell you that or may be not depends on who you are (#developer) 😛


    • Hi Akshay

      The blog post shows it can be done but it’s basically not a good idea as is mentioned by other community members as well in the comments section.

      What the blog post does demonstrate is that administrators and others can get creative in order to change a situation or fix a problem. Not necessarily in the best practice kind of way. So it highlights that much is possible (since SAP runs on a bunch of database tables you can do all kind of tricks).

      Many tricks can seriously mess up your system though so I wouldn’t recommend doing this without good reason.

      Using TOC (Transport Of Copies) for example is a much better way to ensure a transport request holds everything it should hold. It’s the best practice method that is used by the scenario Change Request Management in SAP Solution Manager as well. Only releasing the actual transport request when the change has been tested in acceptance (through TOC transports) makes sense as that bundles everything together in your transport request, avoiding the need for many transport requests).

      Best regards


  • Hello Tom,

    What a fight !

    Your post is 100% clean, I do not understand why people get angry like that!

    SAP himself can even be ruder in OSS notes.

    Thanks for sharing information, only knowledge is important after all 😉


    966688 – CC-INFO: Running SCC1 concurrently with release of transport

    you may update the TRSTATUS field in table E070 for the affected transport using SQL commands if you are comfortable with doing this and know what you are doing. SAP generally does not recommend direct DB updates. Please review with your DBA or technical team on how to do this. You can refer to note 7894 for an example of such SQL commands.

    7894 – Correction locks do not belong to system

    In an emergency, you can also use the following SQL commands to delete the blocks:

    • Hi Yves

      Well, I don’t really think that unreleasing a transport request is a good idea but the blog did also trigger other comments. I do believe we should be able to put such content out there as it generates discussion, highlights what some of us out there might do which can potentially be dangerous or harm the system so in the end I do think the blog post has it’s place.

      However, content wise, unreleasing a transport request is a bad idea. As I mentioned above, best practice to avoid this would be to use Transport Of Copies to ensure the change is good in acceptance and once it is, releasing the actual transport request so everything belonging to that change is bundled together.

      It’s definitely not uncommon for system administrators to change table entries to fix certain situations.

      Just last week I had to delete a couple of table entries to get out of a stuck situation.

      The only thing is, the reason why you would unrelease a transport request that I wrote in this blog post totally sucks 🙂 . It’s not a valid reason at all. Things would have to  be way worse in order to revert to taking this action.

      I think it’s a good idea that I write a new blog post which discusses the topic / comments on this blog post in general which I can then add to the beginning of this blog post.

      Thanks for shiming in.

      Best regards