PERFORM_CONFLICT_TYPE — PERFORM_CONFLICT_TYPE runtime error

PERFORM_CONFLICT_TYPE belongs to the family of runtime type-mismatch dumps triggered specifically by external PERFORM statements, meaning a PERFORM that targets a routine in a different program or is resolved dynamically via a program name in parentheses. Within a single program the ABAP compiler sees both the calling statement and the FORM definition together and rejects a type mismatch at activation. Across program boundaries, or when the target program is only known at runtime, that static check is impossible, so the kernel performs the comparison when the statement actually executes. If the actual parameter's technical type, structure, or table category does not match what the FORM declares for that position, the kernel abandons the call and raises this runtime error rather than silently truncating or reinterpreting the data. It is a defensive dump: the alternative would be memory corruption from misreading a structure with the wrong layout.

If the cause is a signature change with a stale caller, correct the caller to match the current FORM interface and retest both together; this is a code change requiring a transport request. If the cause is an incomplete transport, the fix is transport management, not code: move the missing object into the target system so caller and callee are consistent again, or, if that is not immediately possible, revert the changed side back to match. If the cause is a TABLES parameter type conflict, decide which side is correct and adjust either the caller's internal table declaration or the FORM's parameter typing, favouring a generic table type in the FORM if the routine genuinely needs to serve multiple callers; this needs a change request and regression test of every caller. If the cause is a dynamic PERFORM, the durable fix is redesign: replace the dynamic external PERFORM with a function module or method call that has a strongly typed, compiler-checked interface, which is a larger effort but removes the whole class of risk. If the cause is program buffer desynchronization, a Basis-side buffer refresh or targeted server restart resolves the symptom immediately, but only after confirming the transport itself is complete on all servers.

The first reflex is usually to wrap the PERFORM in a TRY CATCH block expecting to trap the exception the way CALL FUNCTION or CALL METHOD failures are caught. The PERFORM statement does not support an EXCEPTIONS addition or participate in structured exception handling in the same way, so this change compiles, looks reassuring, and does nothing: the dump still terminates the program the next time the mismatched call executes. The second common reflex is restarting the application server or clearing the program buffer because the dump stopped appearing afterward. That only proves the buffer was stale; if the underlying transport gap or signature mismatch is still there, the dump returns as soon as the buffer repopulates from the inconsistent source.

Treat external PERFORM as legacy syntax and avoid it in new development; function modules and class methods enforce interface types at activation time and cannot produce this dump. Where external PERFORM must be retained for existing code, always transport the calling program and the program containing the FORM in the same transport request so they never go out of sync in a target system. Run an extended program check or code inspector variant that flags external PERFORM usage and cross-checks parameter types where the tooling supports it, and treat any warning about generic table types on shared FORM interfaces as a signal to convert the routine to a proper method.

This is an ABAP development problem in the great majority of cases, since the fix is a code or transport correction rather than a configuration or infrastructure change. Basis involvement is limited to confirming or refreshing program buffers when the symptom is intermittent across application servers. The handover note should name the calling program and line, the target routine and its program, the exact parameter and expected versus actual type, and the transport request numbers for both sides of the call.

Diagnosed in ST22 and cross-referenced in SE38, SE80 and SE11; transport consistency is checked through the transport organizer tools and, when a buffer desync is suspected, through SM51. The closest analog for typed RFC-style calls is the CALL_FUNCTION_CONFLICT_TYPE dump, which is the same category of error but for function module interfaces instead of subroutine interfaces, along with its length-mismatch counterpart for function modules.