Lesson 5 of 5
Import failures and how to fix them
9 min
Imports fail. What matters is that the failure is noticed, understood and fixed in the right place before anyone trusts a test result. The first signal is the return code. Every import step writes one, and the import history in STMS (Goto, Import History) shows the highest code per request in its RC column. The transport logs, opened from the queue or history, break that down by step.
| Return code | Meaning | What to do |
|---|---|---|
| 0 | Imported without errors | Proceed |
| 4 | Warnings; all objects were imported | Read the warnings; usually acceptable |
| 8 | Errors; individual objects could not be imported or generated | Stop and analyze before testing anything those objects touch |
| 12 or higher | Serious error, usually not caused by the request content (tool, directory, database or connection problem) | Basis investigates; above 16 points to a failure inside the transport tool itself |
Return codes as SAP's documentation describes them. A code of 8 means part of the request is missing.
How a code is treated depends on the transport strategy. SAP's training notes two tp parameters set by TMS: the code at which an import stops immediately, and the code at which a request counts as unsuccessful and stays in the queue. Under the mass-transport strategy a code of 8 is treated as finished, while under single-transport strategies it counts as a failure. So a request that has left the queue is not proof of a clean import. Always read the RC column.
The usual suspects
| Symptom | Likely cause | Fix |
|---|---|---|
| RC 8 with syntax or generation errors | A program uses an object from a request not yet imported (missing predecessor) | Import the missing request in order, or include the object; do not patch QAS |
| RC 8 with dictionary activation errors | A table or CDS view depends on a field or type in another request | Find the dependency, import in order, reactivate through a new request if needed |
| Old behavior returns after a full import | Overtaker: an older request overwrote a newer version | Reimport the newer request; use Leave in Queue next time |
| A setting flips back to an old value | Two customizing requests recorded the same entry; the last import won | Agree the right value, record it once more in a new request |
| Version check column flags the request | Built on a different release or support package level than the target | Align levels or rebuild; never force without analysis |
| Import does not start; RC 12 or higher | RFC, TMSADM, transport directory or tp profile problem | Basis runs the STMS checks and fixes the infrastructure |
Common failures behind a red line in the import history.
- Read the import historyWhich requests ended with 8 or higher, and in which build?
- Open the log by stepImport, dictionary activation, generation or method execution: the step names the problem
- Identify the objectNote the object name and type from the log
- Find the dependencyWhich request holds the missing or newer version? Check its queue position
- Fix in developmentCorrect with a new request in CMD; never change CMQ by hand
- Reimport and retestConfirm RC 0 or 4, then retest what the failed objects touch
How failed imports invalidate testing
A request with RC 8 still shows as imported in many views, so testers carry on. The object that failed to generate may be missing altogether, or CMQ may still run the previous version. The test then fails for the wrong reason, or worse, passes on old code. Either way the result says nothing about the build under test. That is why Contoso's build notes, posted after each 06:00 import, list every request with RC 8 or higher and the objects affected, and why test cases that touch those objects are blocked until a clean import.
Fixing the failure also has a rule: never repair QAS directly. Activating an object by hand in CMQ or changing a setting there makes CMQ pass while CMP will receive the broken request. The correction belongs in CMD, in a request that follows the same route, so production gets exactly what QAS tested.
- Did every request in the build end with RC 0 or 4?Yes → run the smoke test and start · No → continue
- Do the failed objects touch the processes in today's test scope?No → start, and log the exclusion in the build note · Yes → continue
- Is a corrected request already released and next in the queue?Yes → import it, confirm the RC, then start · No → block the affected cases and raise a defect
What would you do?
Monday's 06:00 import into CMQ shows RC 8 for request CMDK900611, which contains a new CDS view used by the fleet margin report. UAT for order-to-cash starts at 09:00. Maria asks whether her team can begin. What should Priya decide?
- Return codes: 0 clean, 4 warnings, 8 objects failed, 12 or higher a serious tool or infrastructure problem.
- A request that left the queue is not proof of success; check the RC column in the import history.
- Most RC 8 failures are missing dependencies, overtakers or version mismatches.
- Fix in development and transport again; never repair QAS by hand.
- Block only the test cases that touch failed objects, and record it in the build note.
Check your understanding · not graded
Lesson check
1. What does return code 8 mean?
2. Return code 12 or higher usually points to:
3. A program fails to generate in CMQ because it uses a class from a request still waiting in the queue. What is the fix?
4. Why should a failed object never be repaired directly in QAS?