STXH table — SAPscript Text Header Table

Each row in STXH represents one SAPscript text object instance: a specific combination of text object (e.g. a sales order, a material, a purchase order item), text ID (which text slot within that object, such as header text or item note), language, and name (the key that ties the text back to the business document or master record). The row carries administrative data about that text - format, line size, line count, who last maintained it and when - but the actual text content, line by line, lives in STXL. STXH exists so the system can check whether a text exists and retrieve its metadata without reading the full text body. Every long text field on an SAP screen backed by SAPscript, rather than a simple character field, generates entries here when text is saved.

STXH is client-dependent and can be very large in a mature system because every long text saved anywhere, from a scribbled internal note on a purchase order to a formal customer contract clause, creates a row. Never select on TDOBJECT alone or on TDFDATE alone across the whole client - both are low selectivity and the table will have millions of rows in an established landscape. Always restrict on the full composite key: TDOBJECT plus TDNAME plus TDID, and add TDSPRAS if the language is known. If only the business document number is known, first confirm which TDOBJECT and TDID apply to that document type before querying, otherwise the same TDNAME value can exist under multiple unrelated objects and pull in noise.

Symptom: a user claims text was entered on a document but it does not print or does not show on redisplay. Select STXH with TDOBJECT for that document type, TDNAME equal to the document number, and TDID equal to the expected text ID. If no row is returned, the text was never saved under that ID, or it was saved against a different TDID or a different TDNAME format (padding, leading zeros) than expected. If a row exists, check TDLINECNT is greater than zero and then confirm matching lines actually exist in STXL for the same key.

STXH remains a live table in S/4HANA. SAPscript long text storage was not replaced by the S/4HANA data model changes the way many classic tables were, though many newer applications prefer other text storage mechanisms outside SAPscript entirely. Where SAPscript is still used, the same STXH and STXL pairing applies unchanged. No CDS compatibility view is generally needed because the underlying table structure and technology did not change.

A question about missing or wrong long text on a document is first the functional consultant's problem, since the correct TDOBJECT and TDID for that document type are configuration knowledge. The ABAP or basis team gets involved only when STXH and STXL are inconsistent with each other, or when a mass text migration or transport has left orphaned or duplicate entries.

STXL holds the actual text lines for every STXH header and is always checked alongside it. Standard text maintenance happens through the SAPscript text editor transaction rather than direct table entry. T002 supplies the readable name for the TDSPRAS language key. Application transactions across modules - sales orders, purchase orders, material master, vendor master - all write to STXH indirectly whenever a user saves a long text field on their respective screens.