Itab hibernate update#
The use of lazy update also means that these costsĪre often incurred in unexpected places. The construction of a secondary index is costly. Make it unnecessary to copy data to tables with appropriate keys. The example demonstrates that performance is improved significantly by using secondary table keys, which If a secondary key wereĭeclared for jtab, such as a hash key for the first column, the runtime of the last two DELETE statements would be about the same. Shorter since only one key needs to be administered for the internal table. The same as an access to itab using the secondary sorted key, but is a little Table itab but no secondary key as its only key. Internal table jtab, which has the same row type and content as the previous The fourth DELETE statement performs the same delete operation on a sorted.The total of this runtime and the runtime required to construct the index gives the runtime of the second DELETE statement. Statement is faster than the previous two statements. The third DELETE statement specifies the secondary key again, but itĪlready exists due to the preceding method call.The time measured here is largely the runtime needed to create the index. Once the internal table is filled again, the secondary key is constructed explicitly using the methodįLUSH_ITAB_KEY of the class CL_ABAP_ITAB_UTILITIES.Is included in the DELETE statement measurement and seems to make it considerably slower than the previous non-optimized statement. Since this key is not used to access the internal table after the table is filled, the secondary table key must first be constructed The secondary key is specified in the second DELETE statement.This access must perform a linear scan of the entire internal table. For demonstration purposes, the pragma #PRIMKEY is used to suppress the syntax check warning in the firstĭELETE statement stating that the primary key is being used to access the internal table without its component being specified.The program measures the runtime of the statement DELETE itab, with a condition being set after WHERE on the column that determines the secondary key. The method refresh_itab fills the table with 100000 rows, with the second column being given random numbers between 1 and 10. The method refreshitab fills the table with 100000 rows, with the second column being given random numbers between 1 and 10. The table itab is a hashed table with a unique primary key and a non-unique Prng = cl_abap_random_int=>create( seed = + sy-uzeit |Delete without using secondary sorted key: | ).ĭATA prng TYPE REF TO cl_abap_random_int. WHERE with various table keys.ĭELETE itab WHERE col2 = 10 #primkey. This example measures the runtime of the statement DELETE. Internal Tables, Deleting Rows Using WHERE Processing Statements for Internal Tables → SAP NetWeaver AS ABAP Release 752, ©Copyright 2017 SAP AG.
0 kommentar(er)
