STXL table — SAPscript text line storage cluster table

STXL stores the body content of SAPscript texts: the actual lines that make up a long text, a note, a PO item text, a delivery text, a material memo, or any other text object maintained through the SAPscript text editor and the text API (READ_TEXT, SAVE_TEXT, CREATE_TEXT). Each text is identified by the combination of object, name, id and language, mirrored from the header table STXH. Physically, STXL is a database cluster table: the line records for a given text key are packed together and stored as one raw blob in a cluster field rather than as individual rows with plain columns. Logically a consultant thinks of it as one row per text line, format and content, but the storage layer hides that structure behind the cluster mechanism, which is why the table cannot be browsed the way a normal transparent table can.

Always restrict on MANDT first, then on the full key: TDOBJECT, TDNAME, TDID, TDSPRAS. Never select on STXL without at least TDOBJECT and TDNAME, the table is enormous in any live system because every long text ever saved for every document lives here. Because the payload is packed into CLUSTD, a raw SELECT against STXL from SE16 or native SQL will show a header row exists but will not give readable text content; the field appears as binary or truncated garbage. The only safe way to retrieve the actual lines is through the text read function module (commonly READ_TEXT) or through the SAPscript editor itself, both of which unpack the cluster correctly for the given key.

To confirm whether a long text exists for a document, do not query STXL directly. First check STXH with TDOBJECT, TDNAME, TDID, TDSPRAS filled in for the document in question; a row there confirms a text object was created, along with TDLINECNT (line count) and change timestamp. If STXH shows a row but the user reports the text is empty in the transaction, call READ_TEXT with the same key to unpack STXL and see the actual lines returned in the internal table.

STXL remains in use on S/4HANA for classic SAPscript long texts and continues to be accessed through the same text API rather than direct SQL. It has not been replaced by a CDS compatibility view because its cluster storage format is not something a view can meaningfully expose as flat fields. Newer text scenarios increasingly use different storage models outside SAPscript, but wherever SAPscript text objects are still used, STXL keeps its original cluster shape and access pattern unchanged.

Ownership sits with the ABAP developer or technical consultant supporting whatever application uses the text object in question, since only they know the correct TDOBJECT, TDID and calling program. Functional consultants can confirm a text is missing or wrong from the transaction screen, but tracing it in the database requires someone comfortable calling READ_TEXT with the right key rather than querying STXL directly.

STXH is the header table sharing the same key and is the first place to check before touching STXL. Text maintenance happens through the SAPscript text editor embedded in the calling transaction (sales order, purchase order, material master, etc), not through a dedicated maintenance transaction for STXL itself. Custom text access should go through the text read/save/create function modules rather than direct table operations.