Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

read table statement

Former Member
0 Kudos

HI!

In case of 'READ TABLE itab' ABAP

statement if i do not go for binary search what will happen?

And if in case of Binary search if the internal table is not sorted

before READ TABLE statement what will happen??

thankx

Amit

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi Amit,

check these read statements.

READ - Reading an Internal Table

Variants:

1. READ TABLE itab FROM wa additions.

2. READ TABLE itab WITH TABLE KEY k1 = v1 ... kn = vn additions.

3. READ TABLE itab WITH KEY k1 = v1 ... kn = vn BINARY SEARCH additions.

4. READ TABLE itab INDEX i additions.

Obsolete Variants

The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Short Forms of Line Operations not Allowed.

In some cases, the syntax rules that apply to Unicode programs are different than those for non-Unicode programs.See Key Specifications and Unicode.

Effect

Reads an entry from an internal table, using either its key or its index. The return code SY-SUBRC specifies whether an entry could be read. If you specify a non-unique key (the table must have a NON-UNIQUE key for this to be valid), the system returns the entry with the lowest index from the set of entries that meet the condition.

SY-SUBRC = 0:

An entry was read.

SY-TABIX is set to the index of the entry.

SY-SUBRC = 2:

An entry was read.

SY-TABIX is set to the index of the entry. This return code can only occur when you use the COMPARING addition. For further detauls, refer to the COMPARING section of the additions

SY-SUBRC = 4:

No entry was read.

The value of SY-TABIX depends on the table type and whether the BINARY SEARCH addition was specified.

If the table is a SORTED TABLE or a table sorted in ascending order of the type STANDARD TABLE with the BINARY SEARCH addition, SY-TABIX refers to the next-highest index.

Otherwise, SY-TABIX is undefined.

SY-SUBRC = 8:

No entry was read.

This return code only occurs with a SORTED TABLE or a STANDARD TABLE with the BINARY SEARCH addition. SY-TABIX is set to the number of all entries plus 1.

The READ TABLE statement also fills the system fields SY-TFILL and SY-TLENG.

Variant 1

READ TABLE itab FROM wa additions.

Variant 2

READ TABLE itab WITH TABLE KEY k1 = v1 ... kn =

vn additions.

Effect

The system uses the specified table key values to locate the correct line. If there is more than one entry with the same key, the system returns the first. The way in which the system looks for table entries depends on the table type:

STANDARD TABLE:

The system searches from the start of the table. The response time is in linear relation to the number of table entries.

SORTED TABLE:

The response time is in logarithmic relation to the number of table entries.

HASHED TABLE:

The response time is constant.

Notes

When you specify the table key using k1 = v1 ... kn = vn you must specify values for all of the key fields. If the type of a value is not compatible with the type of the corresponding key field,the system uses MOVE logic to convert it to the type of the key field before reading from the table.

If you do not know the name of a component until runtime, you can use the expression WITH TABLE KEY ... (ni) = vi ... to specify it dynamically as the contents of the field ni. If ni is empty at runtime, the key specification is ignored.

If a table has a non-structured line type, you can use the pseudocomponent TABLE_LINE to address the entire line as the table key (see also Pseudocomponent TABLE_LINE in Internal Tables).

If you specify the key implicitly using FROM wa, the values for the table key are taken from the corresponding components of the (structured) field wa. wa must be compatible with the line type of itab. In this way, you can access a table using READ without having to know the table key statically. If the table key is empty, the system reads the first line.

Variant 3

READ TABLE itab WITH KEY k1 = v1 ... kn = vn

BINARY SEARCH additions.

Effect

The system evaluates the specified key to identify the correct line. If the type of a value is not compatible with the type of the corresponding key field, the system uses MOVE logic to convert the value into the type of the component before reading the table. This is an asymmetric comparison logic, in which the component type takes precedence over the value type.

The way in which the system looks for an entry in the table depends on its table type. The system optimizeds the key access whenever possible (see Optimized Key Operations With Internal Tables).

STANDARD TABLE:

If you use the ... BINARY SEARCH addition, the system uses a binary search. Otherwise, the search is sequential. This assumes that the internal table is sorted in ascending order in the sequence of the specified key fields.

SORTED TABLE:

If the specified key fields form a left-justified extract of the table key or are identical with the entire table key, the search is binary, otherwise sequential.

HASHED TABLE:

If the key fields specified are identical with the entire table key, the hash algorithm is used, otherwise read access is sequential.

Notes

The system reads the first entry in which the specified components k1 ... kn correspond with the values of v1 ... vn. If the type of a value and the type of the corresponding key are incompatible, the system uses MOVE logic to convert the value into the type of the component before reading the table.

If your table has a non-structured line type, you can use the pseudocomponent TABLE_LINE to address the entire line as the key (see also Pseudocomponent TABLE_LINE with Internal Tables).

If you do not know the name of a component until runtime, you can use the expression WITH KEY ... (ni) = vi ... to specify it dynamically as the contents of the field ni. If ni is empty at runtime, the system ignores the component. If ni contains an invalid component name, a runtime error occurs. If ni contains an empty name, the system ignores the key specification.

If the line type of the internal table contains object reference variables as componetns or the entire line type is a reference variable, you can use the attributes of the object to which the reference is pointing in a particular line as key values (see Attributes of Objects as the Key of an Internal Tables).

If you specify a completely empty key, the system reads the first entry from the table.

You restrict your specification using offset and length. This is valid for both the static and dynamic variant.

Variant 4

READ TABLE itab INDEX i additions.

Effect

Accessing the table entry with the index i.

Notes

Performance:

The quickest way to access a single line of an internal table is direct access using an index, because the response time is then not linked to the size of the table, and is restricted more or less to the transport costs for a single line.

For hashed tables, the response time is constant. Accessing a table using the hash administration makes the response time around 3 times slower than using index access.

If you use the key to access a table, the response time increase as the number of table entries and the size of the search key increase. Searching using a binary search is considerably quicker than using a linear search. Therefore, in many cases it can be quicker to sort the table and then use the BINARY SEARCH addition.

The runtime required to read a line from a table with 100 entries using the index is around 7 msn (standard microseconds), to read a line using a key of 30 bytes using a binary search, around 25 msn, and without binary search, around 100 msn.

Using statements that use an explicit work area for internal tables with a header line can avoid unnecessary value assignments.

Exceptions

Non-Catchable Exceptions

Cause: Overlapping or duplicate key specifications used when reading a table using READ ... WITH TABLE KEY.

Runtime Error: DYN_KEY_DUPLICATE

Cause: When you read a table of the type SORTED, using the BINARY SEARCH addition, the specified key fields must make up a left-justified extract of the key.

Runtime Error: ITAB_ILLEGAL_BINARY_SEARCH

Cause: Key specification missing.

Runtime Error: ITAB_KEY_COMPONENT_MISSING

Cause: Invalid key specification when accessing a key table.

Runtime Error: ITAB_KEY_ILLEGAL_COMPONENT

Cause: Invalid implicit key specification in the Unicode context.

Runtime Error: READ_ITAB_UC_KEY_ERROR

If Found Help Full Do Reward.

Regards.

Eshwar.

13 REPLIES 13

Former Member
0 Kudos

hi,

To use binary search, the table has to be sorted.

If you are using read table without binary search, it will be a linear search and only the first successful read will be returned, else sy-subrc will be not equal to 0.

Regards,

Subramanian

Edited by: Subramanian PL on Jul 15, 2008 10:37 PM

Former Member
0 Kudos

Hi Amit,

check these read statements.

READ - Reading an Internal Table

Variants:

1. READ TABLE itab FROM wa additions.

2. READ TABLE itab WITH TABLE KEY k1 = v1 ... kn = vn additions.

3. READ TABLE itab WITH KEY k1 = v1 ... kn = vn BINARY SEARCH additions.

4. READ TABLE itab INDEX i additions.

Obsolete Variants

The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Short Forms of Line Operations not Allowed.

In some cases, the syntax rules that apply to Unicode programs are different than those for non-Unicode programs.See Key Specifications and Unicode.

Effect

Reads an entry from an internal table, using either its key or its index. The return code SY-SUBRC specifies whether an entry could be read. If you specify a non-unique key (the table must have a NON-UNIQUE key for this to be valid), the system returns the entry with the lowest index from the set of entries that meet the condition.

SY-SUBRC = 0:

An entry was read.

SY-TABIX is set to the index of the entry.

SY-SUBRC = 2:

An entry was read.

SY-TABIX is set to the index of the entry. This return code can only occur when you use the COMPARING addition. For further detauls, refer to the COMPARING section of the additions

SY-SUBRC = 4:

No entry was read.

The value of SY-TABIX depends on the table type and whether the BINARY SEARCH addition was specified.

If the table is a SORTED TABLE or a table sorted in ascending order of the type STANDARD TABLE with the BINARY SEARCH addition, SY-TABIX refers to the next-highest index.

Otherwise, SY-TABIX is undefined.

SY-SUBRC = 8:

No entry was read.

This return code only occurs with a SORTED TABLE or a STANDARD TABLE with the BINARY SEARCH addition. SY-TABIX is set to the number of all entries plus 1.

The READ TABLE statement also fills the system fields SY-TFILL and SY-TLENG.

Variant 1

READ TABLE itab FROM wa additions.

Variant 2

READ TABLE itab WITH TABLE KEY k1 = v1 ... kn =

vn additions.

Effect

The system uses the specified table key values to locate the correct line. If there is more than one entry with the same key, the system returns the first. The way in which the system looks for table entries depends on the table type:

STANDARD TABLE:

The system searches from the start of the table. The response time is in linear relation to the number of table entries.

SORTED TABLE:

The response time is in logarithmic relation to the number of table entries.

HASHED TABLE:

The response time is constant.

Notes

When you specify the table key using k1 = v1 ... kn = vn you must specify values for all of the key fields. If the type of a value is not compatible with the type of the corresponding key field,the system uses MOVE logic to convert it to the type of the key field before reading from the table.

If you do not know the name of a component until runtime, you can use the expression WITH TABLE KEY ... (ni) = vi ... to specify it dynamically as the contents of the field ni. If ni is empty at runtime, the key specification is ignored.

If a table has a non-structured line type, you can use the pseudocomponent TABLE_LINE to address the entire line as the table key (see also Pseudocomponent TABLE_LINE in Internal Tables).

If you specify the key implicitly using FROM wa, the values for the table key are taken from the corresponding components of the (structured) field wa. wa must be compatible with the line type of itab. In this way, you can access a table using READ without having to know the table key statically. If the table key is empty, the system reads the first line.

Variant 3

READ TABLE itab WITH KEY k1 = v1 ... kn = vn

BINARY SEARCH additions.

Effect

The system evaluates the specified key to identify the correct line. If the type of a value is not compatible with the type of the corresponding key field, the system uses MOVE logic to convert the value into the type of the component before reading the table. This is an asymmetric comparison logic, in which the component type takes precedence over the value type.

The way in which the system looks for an entry in the table depends on its table type. The system optimizeds the key access whenever possible (see Optimized Key Operations With Internal Tables).

STANDARD TABLE:

If you use the ... BINARY SEARCH addition, the system uses a binary search. Otherwise, the search is sequential. This assumes that the internal table is sorted in ascending order in the sequence of the specified key fields.

SORTED TABLE:

If the specified key fields form a left-justified extract of the table key or are identical with the entire table key, the search is binary, otherwise sequential.

HASHED TABLE:

If the key fields specified are identical with the entire table key, the hash algorithm is used, otherwise read access is sequential.

Notes

The system reads the first entry in which the specified components k1 ... kn correspond with the values of v1 ... vn. If the type of a value and the type of the corresponding key are incompatible, the system uses MOVE logic to convert the value into the type of the component before reading the table.

If your table has a non-structured line type, you can use the pseudocomponent TABLE_LINE to address the entire line as the key (see also Pseudocomponent TABLE_LINE with Internal Tables).

If you do not know the name of a component until runtime, you can use the expression WITH KEY ... (ni) = vi ... to specify it dynamically as the contents of the field ni. If ni is empty at runtime, the system ignores the component. If ni contains an invalid component name, a runtime error occurs. If ni contains an empty name, the system ignores the key specification.

If the line type of the internal table contains object reference variables as componetns or the entire line type is a reference variable, you can use the attributes of the object to which the reference is pointing in a particular line as key values (see Attributes of Objects as the Key of an Internal Tables).

If you specify a completely empty key, the system reads the first entry from the table.

You restrict your specification using offset and length. This is valid for both the static and dynamic variant.

Variant 4

READ TABLE itab INDEX i additions.

Effect

Accessing the table entry with the index i.

Notes

Performance:

The quickest way to access a single line of an internal table is direct access using an index, because the response time is then not linked to the size of the table, and is restricted more or less to the transport costs for a single line.

For hashed tables, the response time is constant. Accessing a table using the hash administration makes the response time around 3 times slower than using index access.

If you use the key to access a table, the response time increase as the number of table entries and the size of the search key increase. Searching using a binary search is considerably quicker than using a linear search. Therefore, in many cases it can be quicker to sort the table and then use the BINARY SEARCH addition.

The runtime required to read a line from a table with 100 entries using the index is around 7 msn (standard microseconds), to read a line using a key of 30 bytes using a binary search, around 25 msn, and without binary search, around 100 msn.

Using statements that use an explicit work area for internal tables with a header line can avoid unnecessary value assignments.

Exceptions

Non-Catchable Exceptions

Cause: Overlapping or duplicate key specifications used when reading a table using READ ... WITH TABLE KEY.

Runtime Error: DYN_KEY_DUPLICATE

Cause: When you read a table of the type SORTED, using the BINARY SEARCH addition, the specified key fields must make up a left-justified extract of the key.

Runtime Error: ITAB_ILLEGAL_BINARY_SEARCH

Cause: Key specification missing.

Runtime Error: ITAB_KEY_COMPONENT_MISSING

Cause: Invalid key specification when accessing a key table.

Runtime Error: ITAB_KEY_ILLEGAL_COMPONENT

Cause: Invalid implicit key specification in the Unicode context.

Runtime Error: READ_ITAB_UC_KEY_ERROR

If Found Help Full Do Reward.

Regards.

Eshwar.

Former Member
0 Kudos

Hi Amit,

In the two cases the performance of that application will be down

Regards,

Suresh.S

Former Member
0 Kudos

HI,

Reading a table with binary search is faster than a normal read staement .

Binary search is used if your itab has large number of records.

If you use binary search in read without sort it will not work beacusebinary search works on sorted data.

You can understand by taking an example of searching meaning of a word in dictionary.

Hope it helps.

Former Member
0 Kudos

Hello

1. You will read record from internal table. But it will slowly in contrast with binary search.

2. With big share of probability beside you is not got read line.

Former Member
0 Kudos

Former Member
0 Kudos

Hi,

if you are not use binary search it will search linear

so time taken by the statment will be high..

Former Member
0 Kudos

Read Statement without binary search

Reading Lines of Tables

To read a single line of any table, use the statement:

READ TABLE <itab> <key> <result>.

For the statement to be valid for any kind of table, you must specify the entry using the key and not the index. You specify the key in the <key> part of the statement. The <result> part can specify a further processing option for the line that is retrieved.

If the system finds an entry, it sets SY-SUBRC to zero, if not, it takes the value 4, as long as it is not influenced by one of the possible additions. If the internal table is an index table, SY-TABIX is set to the index of the line retrieved. If the table has a non-unique key and there are duplicate entries, the first entry is read.

Specifying the Search Key

The search key may be either the table key or another key.

Using the Table Key

To use the table key of <itab> as a search key, enter <key> as follows:

READ TABLE <itab> FROM <wa> <result>.

or as follows

READ TABLE <itab> WITH TABLE KEY <k1> = <f 1> ... <k n> = <f n> <result>.

In the first case, <wa> must be a work area compatible with the line type of <itab>. The values of the key fields are taken from the corresponding components of the work area.

In the second case, you have to supply the values of each key field explicitly. If you do not know the name of one of the key fields until runtime, you can specify it as the content of a field <n i > using the form (<n i >) = <f i >. If the data types of <f i > are not compatible with the key fields, the system converts them.

The system searches for the relevant lines as follows:

Standard tables

Linear search, where the runtime is in linear relation to the number of table entries.

Sorted tables

Binary search, where the runtime is in logarithmic relation to the number of table entries.

Hashed tables

The entry is found using the hash algorithm of the internal table. The runtime is independent of the number of table entries.

Using a Different Search Key

To use a key other than the table key as a search key, enter <key> as follows:

READ TABLE <itab> WITH KEY = <f> <result>.

or as follows

READ TABLE <itab> WITH KEY <k1> = <f1> ... <k n> = <f n> <result>.

In the first case, the whole line of the internal table is used as the search key. The contents of the entire table line are compared with the contents of field <f>. If <f> is not compatible with the line type of the table, the value is converted into the line type. The search key allows you to find entries in internal tables that do not have a structured line type, that is, where the line is a single field or an internal table type.

In the second case, the search key can consist of any of the table fields <k 1 >...<k n >. If you do not know the name of one of the components until runtime, you can specify it as the content of a field <n i > using the form (<n i >) = <f i >. If <n i > is empty when the statement is executed, the search field is ignored. If the data types of <f i > are not compatible with the components in the internal table, the system converts them. You can restrict the search to partial fields by specifying offset and length.

The search is linear for all table types. The runtime is in linear relation to the number of table lines.

Specifying the Extra Processing Option

You can specify an option that specifies what the system does with the table entry that it finds.

Using a Work Area

You can write the table entry read from the table into a work area by specifying <result> as follows:

READ TABLE <itab> <key> INTO <wa> [COMPARING <f1> <f 2> ...

|ALL FIELDS]

[TRANSPORTING <f1> <f 2> ...

|ALL FIELDS

|NO FIELDS].

If you do not use the additions COMPARING or TRANSPORTING, the contents of the table line must be convertible into the data type of the work area <wa>. If you specify COMPARING or TRANSPORTING, the line type and work area must be compatible. You should always use a work area that is compatible with the line type of the relevant internal table.

If you use the COMPARING addition, the specified table fields <f i > of the structured line type are compared with the corresponding fields of the work area before being transported. If you use the ALL FIELDS option, the system compares all components. If the system finds an entry with the specified key <key> and if the contents of the compared fields are the same, SY-SUBRC is set to 0. If the contents of the compared fields are not the same, it returns the value 2. If the system cannot find an entry, SY-SUBRC is set to 4. If the system finds an entry, it copies it into the target work area regardless of the result of the comparison.

If you use the TRANSPORTING addition, you can specify the table fields of the structured line type that you want to transport into the work area. If you specify ALL FIELDS without TRANSPORTING, the contents of all of the fields are transported. If you specify NO FIELDS, no fields are transported. In the latter case, the READ statement only fills the system fields SY-SUBRC and SY-TABIX. Specifying the work area <wa> with TRANSPORTING NO FIELDS is unnecessary, and should be omitted.

In both additions, you can specify a field <f i > dynamically as the contents of a field <n i > in the form (<n i >). If <n i > is empty when the statement is executed, it is ignored. You can restrict the search to partial fields by specifying offset and length.

Using a Field Symbol

You can assign the table entry read from the table to a field symbol by specifying <result> as follows:

READ TABLE <itab> <key> ASSIGNING <FS>.

After the READ statement, the field symbol points to the table line. If the line type is structured, you should specify the same type for the field symbol when you declare it. This allows you to address the components of the field symbol. If you cannot specify the type statically, you must use further field symbols and the technique of assigning components of structures to address the components of the structure.

For further information about assigning table lines to field symbols, refer to Access Using Field Symbols.

Examples

DATA: BEGIN OF LINE,

COL1 TYPE I,

COL2 TYPE I,

END OF LINE.

DATA ITAB LIKE HASHED TABLE OF LINE WITH UNIQUE KEY COL1.

DO 4 TIMES.

LINE-COL1 = SY-INDEX.

LINE-COL2 = SY-INDEX ** 2.

INSERT LINE INTO TABLE ITAB.

ENDDO.

LINE-COL1 = 2. LINE-COL2 = 3.

READ TABLE ITAB FROM LINE INTO LINE COMPARING COL2.

WRITE: 'SY-SUBRC =', SY-SUBRC.

SKIP.

WRITE: / LINE-COL1, LINE-COL2.

The output is:

SY-SUBRC = 2

2 4

The program fills a hashed table with a list of square numbers. The work area LINE, which is compatible with the line type, is filled with the numbers 2 and 3. The READ statement reads the line of the table in which the key field COL1 has the same value as in the work area and copies it into the work area. SY-SUBRC is set to 2, because the contents of field COL2 were different.

DATA: BEGIN OF LINE,

COL1 TYPE I,

COL2 TYPE I,

END OF LINE.

DATA ITAB LIKE SORTED TABLE OF LINE WITH UNIQUE KEY COL1.

DO 4 TIMES.

LINE-COL1 = SY-INDEX.

LINE-COL2 = SY-INDEX ** 2.

INSERT LINE INTO TABLE ITAB.

ENDDO.

CLEAR LINE.

READ TABLE ITAB WITH TABLE KEY COL1 = 3

INTO LINE TRANSPORTING COL2.

WRITE: 'SY-SUBRC =', SY-SUBRC,

/ 'SY-TABIX =', SY-TABIX.

SKIP.

WRITE: / LINE-COL1, LINE-COL2.

The output is:

SY-SUBRC = 0

SY-TABIX = 3

0 9

The program fills a sorted table with a list of square numbers. The READ statement reads the line of the table in which the key field COL1 has the same value as in the work area and copies it into the work area. Only the contents of COL2 are copied into the work area LINE. SY-SUBRC is zero, and SY-TABIX is 3, because ITAB is an index table.

DATA: BEGIN OF LINE,

COL1 TYPE I,

COL2 TYPE I,

END OF LINE.

DATA ITAB LIKE SORTED TABLE OF LINE WITH UNIQUE KEY COL1.

DO 4 TIMES.

LINE-COL1 = SY-INDEX.

LINE-COL2 = SY-INDEX ** 2.

INSERT LINE INTO TABLE ITAB.

ENDDO.

READ TABLE ITAB WITH KEY COL2 = 16 TRANSPORTING NO FIELDS.

WRITE: 'SY-SUBRC =', SY-SUBRC,

/ 'SY-TABIX =', SY-TABIX.

The output is:

SY-SUBRC = 0

SY-TABIX = 4

The program fills a sorted table with a list of square numbers. The READ statement reads the line of the table in which the key field COL1 has the value 16. It does not use the table key. No fields are copied to a work area or assigned to a field symbol. Instead, only the system fields are set. SY-SUBRC is zero, since a line was found, and SY-TABIX is four.

DATA: BEGIN OF LINE,

COL1 TYPE I,

COL2 TYPE I,

END OF LINE.

DATA ITAB LIKE HASHED TABLE OF LINE WITH UNIQUE KEY COL1.

FIELD-SYMBOLS <FS> LIKE LINE OF ITAB.

DO 4 TIMES.

LINE-COL1 = SY-INDEX.

LINE-COL2 = SY-INDEX ** 2.

INSERT LINE INTO TABLE ITAB.

ENDDO.

READ TABLE ITAB WITH TABLE KEY COL1 = 2 ASSIGNING <FS>.

<FS>-COL2 = 100.

LOOP AT ITAB INTO LINE.

WRITE: / LINE-COL1, LINE-COL2.

ENDLOOP.

The output is:

1 1

2 100

3 9

4 16

The program fills a hashed table with a list of square numbers. The READ statement reads the line of the table in which the key field COL1 has the value 2 and assigns it to the field symbol <FS>. The program then assigns the value 100 to component COL2 of <FS>. This also changes the corresponding table field.

Binary Search

If you read entries from standard tables using a key other than the default key, you can use a binary search instead of the normal linear search. To do this, include the addition BINARY SEARCH in the corresponding READ statements.

READ TABLE <itab> WITH KEY = <f> <result> BINARY SEARCH.

and

READ TABLE <itab> WITH KEY <k1> = <f1> ... <kn> = <fn> <result>

BINARY SEARCH.

The standard table must be sorted in ascending order by the specified search key. The BINARY SEARCH addition means that you can access an entry in a standard table by its key as quickly as you would be able to in a sorted table.

Example

DATA: BEGIN OF LINE,

COL1 TYPE I,

COL2 TYPE I,

END OF LINE.

DATA ITAB LIKE STANDARD TABLE OF LINE.

DO 4 TIMES.

LINE-COL1 = SY-INDEX.

LINE-COL2 = SY-INDEX ** 2.

APPEND LINE TO ITAB.

ENDDO.

SORT ITAB BY COL2.

READ TABLE ITAB WITH KEY COL2 = 16 INTO LINE BINARY SEARCH.

WRITE: 'SY-SUBRC =', SY-SUBRC.

The output is:

SY-SUBRC = 0

The program fills a standard table with a list of square numbers and sorts them into ascending order by field COL2. The READ statement uses a binary search to look for and find the line in the table where COL2 has the value 16.

Former Member
0 Kudos

Hi Amit.

I would like to suggest, Binary search in READ TABLE definately improves the perfomance.

Sorting is essential for precise searching/finding of records.

I would like to suggest a few references, These are quite similar to your case.

[SDN - Reference for Read table with Binary search| ]

[SDN - Reference for Difference between read table with & without Binary search |;

[SDN - Reference for Binary search in Read using SORT|;

Hope that's usefull.

Good Luck & Regards.

Harsh Dave

Former Member
0 Kudos

Hi,

if your not given Binary Search in read statment, for finding the particular record, internally it follows

linear search(one by one it will search for the record).If u r not sorting the internal table, in read statment if

u r using binary search in such case inernal table records not in sorted format, for searching particular

record it may takes more time than linear search(in some cases).If u want more information plz find binary

search alogrithm then u will be get clear information.

regards,

kishore.

Subhankar
Active Contributor
0 Kudos

HI Amit,

If you use read table with out using binary search it will work fine but performance will down.

If you use read table using binary search you have first sort the ITAB with the key fields specified in the key condition. If you do not sort it ,but use binary search it will not work .

Former Member
0 Kudos

thankx everyone

I have got my answer.