Transport problem - newest versions overwrite by olders during transport

Question

Hello everybody!
I am writing my master thesis, which mainly focuses on problems with transport in SAP, precisely with data inconsistence.
Let's consider the following situation:
In DEV:
1) Create change request R1 containing object O(1),
2) Release R1
3) Create change request R2 containing the newer version of object - O(2)
4) Release R2
In PRD:
1) Import R2 (using Single Import)
2) Import R1
... thus then an older version O(1) is in PRD instead of O(2).
The presented situation is very trivial, however the transport could consist of plenty requests, which contain plenty objects under different requests. If in this case because of some reasons the Single Import is necessary (like some organization prevents from performing an immediate full transport), the transport administrator has to examine all other requests from an import queue, in order to check, if this Single Import do not cause any inconstistencies.
Is there already any tool, which can fully or partly automize this process?
Or maybe anybody has an idea to ensure that the transport is relevant?
On of the solutions is checking every object under all of requests and comparing their versions. Is this effective? Does it totally solve the problem? Does any tool supporting this solution exist?
Do you maybe have any other ideas to solve this problem?
I would be very thankful for your help!
Best regards,
MZ

Answer 1

Thomas:
As far as I understood, you suggest the solution, which would compare timestamp of every object versions. How can I "receive" the information about it? And when should the versions be checked (I mean, before releasing requests, or maybe after releasing, but before import)?
Uwe:
But what if because of some reasons, just one request of this created "request" set is needed? Sometimes Single Imports does not cause any problems and could be even one of the transport strategy. I was thinking more a solution, which would enable a Single Import, but would not allow for data inconsistencies, caused by overwriting the newest version by older versions.
BTW, I was not aware of the fact, that there is no locking in case of customizing requests, thus thank you. To be honest, I do not see any point why in case of Workbench Requests we lock objects, and in case of Customizing Requests we do not. In my opinion it just causes additional problems. Maybe you know, why SAP solved it like that? What kind of advantages does it give? Of course this problem is also interesting.
Sandra:
Yes, DEV+PRD was just to introduce the main idea. The transactions you gave can be of course helpful to find an error, but I was thinking more about comparing versions under two change requests, before the objects are imported to the target system (not between two systems).
Best regards,
Marcin