Change the Transport Request to the Number we decide
We have come across a situation where there are lot of validations because we are upgrading to HR Renewal 2.0 and there are a lot of changes that have to be moved from our validations systems to our real environments.
Validation systems RS4, RS2
Live systems: Dev, Qas1, Qas2, Production.
There are 2 validations performed..
During our first validations, change requests from RS4, RS2 were created, after HR Renewal Upgrades
Later RS4, RS2 had to be refreshed, HR Renewal Upgrades have to be performed and again there were another set of change requests from RS4, RS2 from the second validations.
Now, After our live environment upgrade to HR Renewal, the change requests have to be imported from the 2 validations.
So it is very important that in our second validations we had to set the Transport Request to the Number we decide, so that there will not be a duplicate entry from our first validation.
Last Transport Request Name from the first Validations: EX : RS4K900110, RS2K900131
Second Validations: First Transport Request: RS4K900111, RS2K900132: How can this be achieved?? is the purpose of this document.
it is simple, no access keys or no developer keys required.
2. E070L table
5. Select the LASTNUM, TRKORR
7. Switch on the debugging /h in the menu bar and enter
8. Edit the code “Show to Edit” as shown
9. Enter and Continue
10.Enter the transport Number that you want your transports to start with, in this case i am choosing SIDK900<110>
11. Now Save.
Now test if the changed worked by created a test transport..
12. And it will start with TRKORR+1
This was quite helpful in our project, Hope it will be useful to whoever is going through this document.
SAP has documented this in 1674286 - How to modify CTS transport number range (ABAP).
It also shared other way to do the same table update.
The note talks more about number ranges and updating the DB. But updating the DB can be tricky sometimes. Especially when you have a large landscape where you are not sure about who the DB owner is.
Or you can consider the below example, the statement is executed but 0 rows updated.
The above from application level does exactly the same.
Updating the table from the DB level has never been a problem for me and also it works well if you know how to update it. The example you have quoted above didn't update any rows, because the SQL statement itself is wrong. So it doesn't surprise me.
I had issues when updating configuration tables directly at DB level. Not for this specific table, though.
When there are buffered tables, or when their information is kept in global variables, the update is not recognized by the system, so it generates incorrect behavior. If this is performed via SE16 or other update via "ABAP" tools, then it is correctly handled.
So, unless tested properly, it is better to use the ABAP interface, IMHO.