SAP ABAP Data Element DMC_READING_TYPE (reading type (transparent, pool, cluster, indx-cluster))
Hierarchy
☛ DMIS (Software Component) DMIS 2011_1
   ⤷ CA-EUR (Application Component) European Monetary Union: Euro
     ⤷ CNV_DMC_UTIL (Package) Data Mapping and Conversion: Utilities
Basic Data
Data Element DMC_READING_TYPE
Short Description reading type (transparent, pool, cluster, indx-cluster)  
Data Type
Category of Dictionary Type D   Domain
Type of Object Referenced     No Information
Domain / Name of Reference Type DMC_READING_TYPE    
Data Type CHAR   Character String 
Length 1    
Decimal Places 0    
Output Length 1    
Value Table      
Further Characteristics
Search Help: Name    
Search Help: Parameters    
Parameter ID   
Default Component name    
Change document    
No Input History    
Basic direction is set to LTR    
No BIDI Filtering    
Field Label
  Length  Field Label  
Short 10 ReadType 
Medium 15 Reading Type 
Long 20 Reading Type 
Heading 45 Reading Type (transparent, pool, cluster...) 
Documentation

Definition

The reading type determines the way how the sender data are managed in a data transfer. The following table shows the possible values along with their meaning and the consequences for access plan calculation and reading of the sender data.

  1. Transparent table, handled by access plans with portioning parameter.
    This means that an access plan must be calculated, the different data portions are distinguished by the upper and lower value of a certain field of the migration object's header table. This field is called the portioning parameter.
    When the data are loaded, one portion is read after the other, the data access for a certain data portion in the sender system has the respective upper and lower limit values for the portioning parameter in its WHERE clause
  2. Pool Table (table belongs to a table pool)
    This means that no real access plan needs to be calculated, all data of the respective table are read in one single data access. This is only possible if there are not too many data in this table (less than approx. 100 MByte). Also, it must be a flat migration objects, that means, not a structure hierarchy but only one sender table.
  3. Cluster Table (table belongs to a physical data cluster)
    In this case, no access plan is calculated, but the data are read in portions of 10.000 records each by means of function module DB_SETGET which handles the data access. In addition to logical cluster tables, this reading type can also be applied to pool and transparent tables, in case no further data selection is specified.
  4. INDEX Cluster
    This means that in the activity of the access plan calculation, the sender data are transferred into a cluster-type table (DMC_INDXCL) . The individual data portions are classified by the identifier of the cluster record which is stored in the access plan fields.
    When the data are really transferred, in the sender system, we only need to do an IMPORT FROM DATABASE to get the data that have been transferred to the cluster before out of the cluster.
    Some space is required in the sender system to store the data in the cluster table. Usually a compression rate of 1:10 can be assumed, that means, we need around 10% of the space required for the original tables. In case of Oracle and DB6, report DMC_CREATE_CLUSTER can be used to assign table DMC_INDXCL to a certain table space.
  5. INDEX Cluster with Full Table Scan
    The only distinction to the reading type above is that it is enforced that when the cluster is loaded, the sender table data are read without using an index, but a full table scan is done.
  6. INDEX Cluster filled by external processing
    This is to be selected if the data will be read from the cluster table the same way as if reading type 4 or 5 is selected. However, in this case, it is the responsibility of some external agent to put the selected data into the cluster table and to communicate the relevant information (amount of selected data; cluster addresses where data are stored....) to the Migration Workbench
  7. INDEX Cluster filled by child table full table scan
    Like 5, but performance optimization for such objects in which the header table is read-only, and there is exactly one child table to be processed. Only applicable if all data of the read-only header table can be stored in an internal table, unless parallelization makes sure that the header table data are subdivided among multiple processes.

History
Last changed by/on SAP  20141030 
SAP Release Created in 620