STRING type or SSTRING element for a text field in table? Pros and cons

Question

I need to create a Z table to store reasons for modifications of a certain custom object.

In the UI, the user will pick a reason ID and then optionally fill a text box. The table will have more or less the fields below:

key objectID
key changeReasonID
    changedOn
    changedBy
    comments

My doubt is with the comments field. I read the documentation about the limitations of STRING and SSTRING, but it's not clear to me if a STRING type field used in a transparent table has a limited length or not.

Even if the length is not limited (at least by the DB), I'm not sure if it's a good idea to use this approach or would you recommend CHAR/SSTRING types with a fix length instead?

**My system is running MSSQL database.

STRING and RAWSTRING have an "unlimited" length (probably something like 2GB and limited by database space available of course - maybe it could be more but ABAP limit is 2GB anyway). — Sandra Rossi

Florian Florian · Accepted Answer · 2020-03-23T15:04:24

Strings have unlimited length, both in ABAP structures/tables, and in the database.

Most databases will store only a pointer in this column that points to the real CLOB value which is stored in a different memory segment. As a result, they restrict the usage of these columns, and may not allow you to use them as a key or index.

If I remember correctly, ABAP supports a maximum of 16 string fields per structure, which naturally limits its use cases. Also consider that ABAP structures have a maximum size.

For your case, if the comment will remain the only long field, and if you are actually fine with storing unlimited input (--> security constraints?), string sounds like a reasonable option.

If you are unsure what the future will bring, or to be on the safe side regarding security, you might want to opt for sstring or simply a long char instead.

STRING type or SSTRING element for a text field in table? Pros and cons

1 Answers