Data clusters
are stored in a storage medium with the help of the statement EXPORT ( see: Statements for Data Clusters) . This is achieved using the different variations of the addition medium. These are as follows:
· DATA BUFFER xstr for storage in a byte string xstr
· INTERNAL TABLE itab for storage in an internal table itab (Standard table)
· MEMORY ID id for storage under the name id in the ABAP Memory
· DATABASE dbtab ... ID id for storage under the name id in a database table in the ABAP Dictionary
· SHARED MEMORY dbtab ... ID id and SHARED BUFFER dbtab ... ID id for storage under the name id in the cross-transaction application buffer of the applications server's shared memory.
In the following you will learn more about the temporary storage of data clusters in ABAP memory and shared memory, as well as permanent storage in databanks. You can find detailed information about the different storage media in the keyword documentation.
ABAP Memory
ABAP memory is a memory area within the internal session (roll area) of an ABAP program and any other program called from it using CALL TRANSACTION or SUBMIT.
ABAP memory is independent of the ABAP program or program module from which it was generated. In other words, an object saved in ABAP memory can be read from any other ABAP program in the same call chain. ABAP memory is not the same as the cross-transaction global SAP memory. For further information, refer to Passing Data Between Programs.
This allows you to pass data from one module to another over several levels of the program hierarchy. For example, you can pass data
· from executable programs that have been called using SUBMIT
· From a transaction to an executable program.
· Between dialog modules.
· From a program to a function module.
and so on.
The contents of the memory are released when you leave the transaction.
Database Tables
You can store data clusters in databases in the ABAP Dictionary. In order to do so, you must create databank tables with a special structure. SAP provides a template databank table called INDX, which you can copy and modify. This is why we also make reference to INDX type tables (see the keyword documentation).
This method allows you to store complex data objects with deep structures in a single step, without having to adjust them to conform to the flat structure of a relational database. Your data objects are then available system-wide to every user. To read these objects from the database successfully, you must know their data types.
You can use INDX-type database tables to store the results of analyses of data from the relational database. For example, if you want to create a list of your customers with the highest revenue, or an address list from the personnel data of all of your branches, you can write ABAP programs to generate the list and store it as a data cluster. To update the data cluster, you can schedule the program to run periodically as a background job. You can then write other programs that read from the data cluster and work with the results. This method can considerably reduce the response time of your system, since it means that you do not have to access the distributed data in the relational database tables each time you want to look at your list.
Although INDX type tables are normal databank tables from the ABAP Dictionary, you should only use them in conjunction with the special statements for data clusters. Only in exceptional cases, for example in order to delete many data clusters from one area with a single statement, can you use Open SQL statements. In order to do this you must have a good working knowledge of the structure of INDX type tables and it is recommended that the table and its contents first be checked for different application cases using the data browser of the ABAP Workbench (transaction SE16).Although it is possible to access an INDX-type database using SQL statements, it is only possible to interpret the structure of the data cluster using ABAP statements.
Cross Transaction Application Buffer
The cross transaction application buffer is a storage area on an application server which all ABAP programs of the SAP system running on the same applications server can access. Data clusters in the cross transaction application buffer are exactly the same as data clusters that are organized in databank tables. Here we will refer to the databank table dbtab. The data are not stored in the databank table itself but in a table with a corresponding set up. Therefore the databank table dbtab must also be an INDX type (see keyword documentation). The structure of this table is then copied for the storage of the cluster in the buffer. This gives you the possibility to store your own administrative information in every cluster in the buffer and import it again as necessary.
The difference between the application buffers SHARED MEMORY and SHARED BUFFER lies in how the system reacts when the storage limit is reached (see Keyword documentation).
reward points if it is usefull .......
Girish
Bluesky
