Skip to Content

The most misunderstood thing about transports

Quick SAP  transport quiz: 

Let’s say I have a table with a configuration with 3 settings–a, b, c.  The initial state of the table is blank.

 

I first save to setting a to transport #1001

I come back later and change the setting to b but I save to transport #1002

Lastly, I come back again and save the table with a value of c and save to #1003

 

I then release the transports and direct the basis team to move the transports to my QA environment in the order #1001, #1003, and lastly #1002 .

 

What value will be transported? (Read to the end of the blog for the answer)

When I went through SAP HR training many, many moons ago, I recall being impressed with the thoroughness of the curriculum.  My training was several weeks in length and went through SAP HR soup-to-nuts. 

However, I remember being distinctly shocked on my first assignment when I was tasked with updating some configuration and then being asked to place my changes something called a transport.  Back then, the most common use of the term “transport” was a minivan from Pontiac.  Wasn’t sure what to do! 

My point is that functional resources are often given precious little guidance on the nature of transports.  

The objective of this blog is to clear up a single misconception about transports.   It’s a misconception that I held for a long time myself.  It was not until I was able to play “junior basis dude” on an internal system that I fully understood how the alchemy of transports actually works.  A quick summary:

  1. When I press save in my config step and am prompted for a transport request, an entry is written internally to the transport record that “points” to the row in the table where I made the change.  The contents of the table are not written to the transport.
  2. I can go back to the same table to the same row and change the value as often as I’d like and there will be no change–but nothing new is written to the transport.
  3. When I release my transport, SAP takes a snapshot of the content of the row and writes to a file.  This file is then moved and updated in the new environment.

Armed with a better understanding of how transports work, let’s revisit the quiz from before.  As we learned, what gets written to the transport is the table’s current value at the time of release.  Since the transports were all released at the same time, they will all have the same value–C.  Therefore, this is the value that gets transported regardless of transport order.

Hope you’ve enjoyed this blog.  Follow me on Twitter @brandontoombs to find out what ridiculously entertaining subject I tackle next.

4 Comments
You must be Logged on to comment or reply to a post.
  • Hello Brandon

    Have you ever wondered why you can save the same customizing entry into multiple transport requests but a repository object (e.g. a report) only into a single one?
    The reason is that the SAP system sets a lock entry for each repository object put into an editable transport request. Whenever you touch this repository object the system will point you to the single request and may ask you to create a new task for you. Such a locking mechanism would not make sense for individual customizing records.

    If you need versioning of customizing settings (even of attributes within the same record) you need to go for BC sets (perhaps my knowledge is already outdated and there are newer technologies available).

    Regards
      Uwe

  • As long as the transports are imported in the same sequence that they’re exported, then you should have no problems.
    Here’s another quick question…
    What do you think happens if you delete the table entry that the transport points to before you release the transport?
  • This is heppend when you crate mass No. of request againt a task or job. we adupt following procedure for request text which is easy to identify the proper sequence of request :

  • I’m not a Basis type person.  They are amazing and wonderful people.

    If you transport a program – The transport will take a snapshot of that VERSION of the program.  So if you change it again after a transport is released – it will prompt you for another change request.  

    We often have fun with our transports.  (I love my Basis team for the fixes they do for me.)  Our development box doesn’t have much data.  We program on our Sandbox system.  Download/Upload to development.  Even after we transport to Sandbox everything may work correctly.  Because that is where we did our development all the objects are there.   So once we transport to our quality box – well – there can be issues.   (Missing objects.)  Lucky for us we do transport to quality and do catch everything there.  Not so lucky because things can run “a muck”.

    Thanks for the blog!  I never really thought about the table changes and how they were transported.  Now I know.

    Michelle