Content Table
Use
In the table CONTENT, the binary table, contents are directly transferred. The transfer occurs via an internal table. The corresponding field is called LINE.
|
Field |
Data element |
Data type |
Length |
Description |
|
LINE |
SDOK_SDATX |
RAW |
1022 |
Line for binary document content, length for upload |
If a caller transfers the content of a document in the binary table and at the same time defines that the mime type is text/Subtyp, the document is handled as a text document, that is, it is converted into the current R/3 code page and stored as text.
Several components of various documents can be transferred in one content table: A new line is started for each component and the size of the individual components ( Component Table) gives the start and end (line x) in the content table.
In the table ASCII_CONTENT, the ASCII table, contents are directly transferred. The transfer occurs via an internal table. The corresponding field is called LINE.
|
Field |
Data element |
Data type |
Length |
Description |
|
LINE |
SDOK_SDAT |
CHAR |
1022 |
Line for text document content, length for upload |
Several components of various documents can be transferred in one content table: A new line is started for each component and the size of the individual components (table COMPONENTS) gives the start and end (line x) in the content table.
In the Content table, one text line is transferred per table line. Line breaks are recognized implicitly by the character space after the last character, that is, there are no explicit line breaks. Continuous text can be defined for applications with very long text lines. This can be implemented using the statement text_as_stream = 'X': Carriage Return and Line Feed are in the text implicitly. Therefore, line breaks can be specified explicitly.