SAP function moduleObjectSAVE_TEXTModuleABAP

SAVE_TEXT — Saving SAPscript long text objects

SAVE_TEXT is the standard, released function module for writing SAPscript long text objects (STXH/STXL) to the database. It is the write-side counterpart to READ_TEXT. It takes a THEAD-like header identifying object, ID, name and language, plus a table of text lines, and either commits directly or queues the save to the update task depending on the SAVEMODE_DIRECT flag.

This page covers SAVE_TEXT, the function module used to persist SAPscript/long texts attached to business objects such as materials, purchase orders, or notes. It focuses on the exception handling that is routinely skipped, the update-task versus direct-save distinction that causes silent data loss, and the key naming mistakes that make saved text unreachable by later reads.

Published 16 Sept 2026· 1,039 words

What it does

SAVE_TEXT writes a long text object into the SAPscript text tables, most commonly STXH for the header and STXL for the line content. It is released for customer use and is the pair-partner of READ_TEXT: whatever gets written by SAVE_TEXT is what READ_TEXT retrieves later. It is used anywhere a program needs to attach or update a free-text note to a business object identified by a text object type, a text ID, a name (usually the object key), and a language, for example internal notes on a purchase order, header texts on a sales document, or custom long-text fields on Z-tables that reuse the SAPscript text infrastructure instead of building their own long-text storage.

Parameters

CLIENT - importing, defaults to sy-mandt, the client the text belongs to; almost never overridden
HEADER - importing, structure like THEAD; must have TDOBJECT, TDNAME, TDID and TDSPRAS filled correctly since these four fields form the key that identifies the text
SAVEMODE_DIRECT - importing flag; when set, the save happens immediately against the database; when left blank, the save is queued to the update task and only becomes durable when the calling LUW issues a commit
INSERT - importing flag; forces insert-only behavior rather than update-if-exists, relevant when the caller must guarantee no prior text is silently overwritten
OWNER_SPECIFIED - importing flag indicating the caller has already filled TDOWNER in HEADER rather than letting the system default it
LOCAL_CAT - importing flag affecting how the local text catalog is handled
LINES - tables parameter like TLINE, the actual text content as a sequence of format and line entries

Exceptions

ID - the text ID in HEADER-TDID does not exist for the given text object; usually a typo in TDID or a text ID that was never configured for that object type
LANGUAGE - HEADER-TDSPRAS is blank or not a valid language key for the system; frequently caused by leaving TDSPRAS uninitialized instead of setting sy-langu explicitly
NAME - HEADER-TDNAME is blank, wrongly padded, or does not match the key format the object expects; a very common cause is passing a document number without the leading zeros the object's text ID demands
OBJECT - HEADER-TDOBJECT does not exist in text object customizing at all
When sy-subrc is not checked after the call, none of these failures raise a runtime error; the function simply returns without writing anything, the caller proceeds believing the text was saved, and the gap only surfaces much later when a READ_TEXT call for that same key comes back empty with no diagnostic trail pointing back to the failed save

How to call it safely

Clear and populate a THEAD-typed structure with TDOBJECT, TDID, TDNAME and TDSPRAS before anything else; these four values are the lookup key and must match exactly what a later READ_TEXT will use. Build the LINES table with TDFORMAT and TDLINE for each line, keeping in mind the maximum line length for the text ID in use. Call SAVE_TEXT and check sy-subrc immediately against all four exceptions rather than assuming success. If SAVEMODE_DIRECT was left blank, ensure the enclosing logical unit of work reaches an explicit commit; if the calling transaction can roll back after this point, either set SAVEMODE_DIRECT or accept that the text write shares the same rollback boundary as everything else in the LUW.

ECC vs S/4HANA

SAVE_TEXT remains available and functionally unchanged on S/4HANA; the underlying STXH and STXL tables are still in use and no SAP-announced successor replaces this pair for classic SAPscript long texts. Some newer document types on S/4HANA use different long-text or content-management mechanisms rather than plain SAPscript text objects, so whether SAVE_TEXT is still the right tool depends on which object is being extended, not on the release. For clean-core discussions this is a standard released API, not a workaround, so calling it directly from custom code is acceptable practice.

Common pitfalls

Leaving SAVEMODE_DIRECT blank and never issuing a commit; the text sits queued in the update task and is lost if the program ends, dumps, or the update task itself fails before a commit happens
Passing an unconverted key into TDNAME, for example a material or document number without its leading zeros, so the text is saved under a key that standard read logic never looks up
Calling SAVE_TEXT with SAVEMODE_DIRECT set inside a larger business transaction that can still roll back; the text is now committed independently of the rest of the document, leaving an orphaned text if the surrounding transaction fails
Reusing the same LINES internal table across a loop over several documents without clearing it first, so later saves silently carry forward stale lines from an earlier iteration
Assuming a successful sy-subrc means the text is visible everywhere immediately; under update-task mode there is a window before the commit where a parallel READ_TEXT still returns the old content

Whose problem this is

The ABAP developer maintaining the program that calls SAVE_TEXT owns getting the header key and commit handling right. The functional consultant who owns the business object (materials, purchase orders, sales documents, and so on) owns the text object and text ID customizing that defines what valid TDOBJECT and TDID values exist and what length TDNAME must be.

Related objects

READ_TEXT is the corresponding retrieval function module and any investigation into a missing text should always cross-check both. The persisted data lives in STXH (text header) and STXL (text lines), with the valid text object and text ID combinations governed by text object customizing tables outside this function module's scope. Programs that need to display rather than persist the same content typically pair a SAVE_TEXT call with a later READ_TEXT and a text editor control on the screen.

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Source: ERPClimb — https://erpclimb.com/sap-function-modules/save-textERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.