ABAP News for Release 7.51 – New Structure for Export/Import Tables
When using the EXPORT/IMPORT statements to write or read data clusters to and from database tables, shared memory or shared buffer, since eons you have to use a predefined data structure that was explained in the documentation and for which the good old database table INDX represents an example.
But hello? Why is the data cluster spread over several lines with additional administration columns SRTF2 and CLUSTR? Never heard about BLOBs (usable since 6.10 or so)?
Now, finally, Yippee! A new variant of export/import tables for data clusters in ABAP 7.50! The structure is similar to the previous one but simplified as follows:
- The same key fields as before, but no SRTF2 any more
- Any number of selfdefined fields
- A final field CLUSTD of type INDX_CLUST_BLOB defined in the ABAP Dictionary having the built-in type RAWSTRING, no CLUSTR any more
It’s about time. Don’t you think so?
You can use the new structure exactly as the old one and, of course, for new export/import tables we recommend the new way.
Here’s an example:
And here its trivial usage:
CALL TRANSFORMATION id
SOURCE ...
RESULT XML xmlstr.
EXPORT xml = xmlstr TO DATABASE demo_indx_blob(xm)
ID '...'.
...
IMPORT xml = xmlstr FROM DATABASE demo_indx_blob(xm) ID '...'.
Same as before, but better behind the scenes.
For more information see Export/Import Tables.
An important improvement indeed.
However, since we need to support “legacy” NW 7.0 systems, I wonder what would be the best solution (size efficient) to save hugh datasets in DB: Using old (multiple rows) data cluster table or a simple DB table with single RAWSTRING field.
I have done some tests and the results were quite confusing.
I’ve saved an internal table of MARA with 5000 records.
For conversion to XSTRING I used the EXPORT TO DATA BUFFER (COMPRESSION ON) command.
The results:
How/why is that?
See https://answers.sap.com/questions/293132/cluster-table-mistery-cluster-table-vs-rawstring.html