SE39 — Splitscreen Editor for ABAP Source Comparison
SE39 is the split-screen editor used to compare two versions or two objects of ABAP source code side by side, typically an active version against an inactive one, or a program against another program or a version from history. It highlights line-level differences and lets a developer copy blocks across, but it does not save anything itself; the underlying object still has to be saved through SE38 or SE80.
This page covers SE39, the ABAP split-screen comparison and merge editor used to resolve conflicting versions of source code. It focuses on where the tool sits between version history, transports and the actual editor, and the diagnostic sequence for the most common confusion: expecting SE39 to persist a change on its own.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,044 words
Purpose
SE39 opens two panes of ABAP source side by side so a developer can visually compare them and, if needed, copy lines from one side to the other. The comparison can be between two arbitrary programs, two includes, or between different versions of the same object pulled from the version history tables. The structural fact that explains most confusion: SE39 is a viewer and merge assistant, not an editor of record. It does not commit anything to the database by itself. Any change made inside SE39 only becomes real once the resulting source is saved through the normal program editor, which is why developers sometimes believe a merge 'did not save' when in fact they never triggered the underlying save at all.
When it is used
SE39 gets reached for during conflict resolution, not during normal development. Typical triggers are a program that fails to activate and needs comparing against its last active version, two developers who worked on the same include and need their changes reconciled before transport release, or a retrofit scenario where the same object was modified in two different system landscapes and the differences need to be understood line by line before deciding which version to keep. It is not used for routine coding, and it has no Fiori counterpart because it is a developer tooling function, not a business transaction. Modern ABAP development in Eclipse-based tooling offers an equivalent compare view, but SE39 remains available as the GUI-based fallback.
How to use it in practice
- Call SE39 and choose the comparison type: program against program, version against version, or active against inactive.
- Enter the object name and version identifiers for both sides of the comparison.
- Execute the comparison; differing lines are highlighted between the two panes.
- Use the copy function to pull selected blocks from one pane into the other where a merge is needed.
- Exit SE39 and open the target object in its normal editor (SE38 or SE80) to confirm and explicitly save the merged result.
- Check the object into a transport if the change needs to move forward.
Key data objects
- REPOSRC - stores the actual ABAP source code lines that SE39 reads to build both comparison panes.
- VRSD and VRSX - version management tables holding the metadata and compressed source of historical versions used when comparing against version history.
- D010INC - include program relationships, relevant when the comparison spans a main program and its includes.
- TADIR - checked to confirm the objects being compared actually exist as repository objects before the comparison is offered.
How to prove it in the data
To confirm a merge actually persisted, do not look inside SE39 itself. Open REPOSRC via SE16 for the program name in question and check the UDAT and UNAM fields (last change date and user) to see whether the object was saved after the comparison session. To confirm a new version was created as a result, check VRSD for the same object name and look for a version entry with a timestamp matching the save. If neither shows a recent update, the merge was viewed but never committed.
ECC vs S/4HANA
SE39 is unchanged on S/4HANA; it still functions as the GUI split-screen comparison tool and there is no dedicated Fiori app replacing it, since it is a development tool rather than a business transaction. Developers working through Eclipse-based ABAP tooling have an equivalent built-in compare and merge view there, and many teams now prefer that over SE39, but the transaction itself has not been deprecated or functionally altered.
Common pitfalls and how to diagnose them
- Empty or trivial diff: the comparison shows no differences even though a discrepancy is expected. Usually the wrong version was selected on one side, most often comparing the active version against itself instead of against the inactive or historical version. Reconfirm which version identifier each pane actually points to before assuming the objects are identical.
- Merge appears lost after leaving SE39: the developer copied blocks between panes but never opened the underlying object and saved it through SE38 or SE80. SE39 holds the merged text only in the session; closing it without an explicit save in the real editor discards the work.
- Lock conflicts during merge: because the target object is opened for edit as part of the workflow, another user already editing the same program produces an enqueue lock error. Check the lock entries for the object name before assuming SE39 itself is broken.
- Cross-system version mismatch: comparing a local development version against a transported version in another system produces a diff driven by transport timing rather than by an actual code difference. Confirm which system and client each version was pulled from before drawing conclusions.
- Whitespace and formatting noise: pretty-printer differences or trailing whitespace show as diffs and obscure the real logical change. Scan for actual statement-level differences rather than reacting to every highlighted line.
Whose problem this is
This is exclusively an ABAP development concern; functional consultants have no reason to open SE39. Basis gets involved only if a lock conflict or transport inconsistency surfaces during the merge. A clean handover from a developer to another developer or to Basis states which two versions were compared, which side was chosen as the merge source, and whether the result was already saved and transported.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/se39ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.