Skip to Content

Export table content using a transport of copies #sapadmin

Exporting table content using a transport of copies is sometimes used to export table data out of a SAP system before the database is refreshed. Once the database is refreshed the transport request is imported again to insert the entries back into the table. There are other means of exporting table data of course but some tables cannot be exported using the EXP or BR*Tools from Oracle for example so this can come in handy.

*EDIT Note that using Oracle EXP seperately is not supported by SAP so I don’t recommend you start using EXP.


Picture 1.0

Go to transaction SE01

Click on Request à \ Create


Picture 1.1

Select Transport of copies

Click yes


Picture 1.2

Provide a short description for your transport request

Enter the SID of your SAP system in the Target field

Click save


Picture 1.3

Now double-click the Request <SID>K90043 (for example) \ under the header Modifiable


Picture 1.4

Click on the Pencil icon to go into change mode


Picture 1.5

Now insert R3TR TABU into Pro Obj columns

Insert the name of the table you wish to export in the \ Object Name column


Picture 1.6

Now click on the key Icon next to the Object Name column


Picture 1.7

If you want to export the full table content insert a * into \ the Table Keys field



Picture 1.8

If you now go back into transaction SE01 you will notice the \ Table Contents appearing under the transport request.


Picture 1.9

Place your cursor on the transport request and push the \ release button to release the transport request. At that moment the table data \ will be exported into the transport request.

Once the transport request is released (and the release \ finished successfully) you should see the data- and cofile of this transport \ request in your transport directory. You can then use the transport request to \ import the table data again at a later points in time (after a database refresh \ for example).

You must be Logged on to comment or reply to a post.
    • Hello Ricardo

      Thanks for your comment.

      Exporting table content as described in the blog uses R3trans -w to place the content in a transport request.

      Note 1942 - How does R3trans work?

      Extract from SAP Note 1942:
      "R3trans can also be used for data migration (export from the old system with the old R3trans and import into the new system with the new R3trans)."

      So yes you can also export seriously big tables using this method.

      Typical tables that are exported before the refresh of a database and imported afterwards again are not large at all.

      Kind regards


  • Hi Tom,

    as usual, quite a real-life focussed blog post.
    Thanks for keeping this up!

    One comment though:
    Data export/import via Oracle EXP/IMP (or EXPDB/IMPDP) is supported _only_ when used with the BRTOOLS for reorganisation purposes.
    There are several things that can be done wrong here easily, leading to crippled data (NLS conversion!) so this really shouldn't be considered an option for moving data between two systems.

    Nevertheless, what kind of data did you had in mind when you wrote, that EXP cannot export all types of data? Technically, all data storing oracle objects can be exported.


    • Hello Lars

      Thanks for your comment.

      RFCDOC table for example which is a pool table.

      We have Oracle EXP in place to export data from system AA1 (for example) before Oracle DB refresh and then inserting the data back in AA1 after Oracle DB refresh is finished. We haven't experienced issues with it yet.

      Kind regards


      • πŸ™‚ as I wrote "Oracle data store objects" ...
        Of course you cannot access pool/cluster tables directly, but only the base tables for those.

        Concerning your experience: sure, the EXP/IMP can work and can lead to the correct results.
        That's true for many features and still, it's just not supported.
        So, when somebody reads this post, tries it out and something goes wrong - we (SAP) won't support this.

        For your scenario I would consider the usage of
        transportable tablespaces anyhow - much faster, much safer.
        Or - if you do this just to protect your application data during the upgrade - simply offline the tablespaces with the application data during the upgrade πŸ˜‰


        • Hello Lars

          Yeah I know πŸ™‚

          It's not my intention to pursuade people not to follow SAP supported way. The EXP was already in place before I joined in.

          I'll place an edit in the blog post to mention it.

          Thanks for the tips.

          Kind regards


  • ... but be careful when entering the key values. If you add a key that doesn't exist, when the transport is released, there is a risk that you will end up with a transport that can delete records in the target system.
    • Hello Michael

      Thanks for contributing to the added value of the blog.

      Does that make sense that it would delete records or should it be considered as a bug?

      Kind regards


      • It's necessary because it's the only way to remove items in a target system. For example, if you delete a role in PFCG in your development system, you are warned that first you need to add the role to a transport, otherwise the deletion will not be replicated to downstream systems.
        If misued, however, it can lead to confusion, especially as there is no "whoops" button in STMS to undo an inappropriate transport...
        • Hello Michael

          I know SAP has got some "hidden" codes and tricks to operate R3trans as well to get systems back on track in really sticky situations. I would love to get my hands on those πŸ˜‰

          I agree with the fact that these types of actions should be practiced carefully but then again that's always the case for administration actions.

          If you don't know what you're doing you can mess up your SAP system. There could and perhaps should be warnings triggered when performing some of the more dangerous administration actions.

          Exporting the wrong tables or not enough tables (not taking into account table relationships) can also cause inconsistencies and basically aid in messing up your SAP system.

          I plan to create some more tips / tricks blogs for #sapadmin's. I'm aware that some actions are tricky / dangerous or even expose security risks (if security is not tight enough) and I'll do my best to highlight that in the blogs but in the end I do feel like these kind of actions should be known by #sapadmin's to resolve certain issue or problem situations.

          Kind regards


    • Hello Abnash

      Thanks for your comment.

      The link you provide is indeed a good contribution to this blog as it provides related information on selecting a range of records instead of a full table.

      There is a fundamental difference though between the blogs. The link that you provide shows a workbench request creation in a development system (presumably a development).

      My blog shows a transport of copies creation which can be used to export table content in a QAS system with as target my QAS SID (for a refresh scenario for example). I would not be able to perform these actions by creating a workbench request in my QAS system due to the way TMS is configured.

      Kind regards


  • Nice blog.
    We've been using this technique for years when applying HR Support Packages.
    If you don't export the content of tables T512W and T512T before applying the HR SP and reimport them after applying the HR SP, you break the payroll !
    • Hello Olivier

      Thanks for nice info addition on HR πŸ™‚

      This blog is gaining more value each comment, love it!

      Kind regards


    • Hello Olivier

      I was wondering if you have experience with report RPU12W0S for the HR wages backup/copy as alternative method to using a transport request.

      Kind regards


      • Hello Tom,

        Yes we know RPU12W0S but our payroll consultant tells us that the result is not good enough for him.
        We even now export and reimport tables T511K and T511P together with T512W and T512T.


    • I wonder if your consultant knows that exporting and importing the tables after SP update will introduce a risk of deleting your data because there’s a chance it changes some fields during that process.

      There should be documentation to support your goal from SAP, but the export import method is not one of that.

      I would suggest trying it in a sandbox environment first and testing everything works beforehand if you really need to do that.

  • Hello Tom.

    great post, thank you.

    One additional question. Do I have to create a transport request in every client or is it possible to export table entries client independent in one transport request.


    • Hello Andreas,

      Thx for your comment.

      Using * as mentioned in this blog post will export all entries meaning the data of that particular table for all clients.

      You can of course also export the data of multiple tables in a single transport request. You can set the key value per table so you can export table A for all clients and table B for a single client as well for example.

      You can take a look at the other blog that is linked in the comments to see how you can select data from a single client.

      Kind regards


  • Hi Tom,
    As usual Heartiest Thanks for the blog which gets used in our work.

    Tom, I am trying hard to understand the difference b/w Workbench and transport of copies.But am not able to conclude well with the comments below.
    I remember,in a similar situation to copy entries of a table I created a Workbench request as we generally deal only with workbench and customizing entries. Can you please tell me?


    • Hello Kumud

      The choice depends on how your transport routes are set up. I could use workbench request if I was exporting the table content from the development SAP systems because there I can choose a consolidation route

      In the example shown in this blog though the table content is exported from acceptance and there is no consolidation route from acceptance to production hence I cannot provide a proper target for a workbench request.

      A transport of copies can have the SAP system itself as target instead of a transport route and that's why this is used here.

      Hopefully that makes for a better explanation but if you want some visuals on that I'll mail it to you if you want to be able to give a better explanation. Visuals work better than words sometimes.

      Kind regards


        • Hell Kumud

          It's not impossible to create a workbench request without a consolidation route but it is considered dangerous at least as you can cause inconsistencies.

          A transport of copies does not get added to the import queue of SAP systems down the transport route automatically.

          I'll send you a word doc with some explanation.

          Kind regards