Application Development and Automation 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 only

How to read time dependent attributs from hashed table

Former Member
0 Likes
635

I have created a hashed table, containing HR data. The records are time dependent.

For example:

Employee datefrom dateto emplstatus job

1234 20091101 20091130 2 1234567

1234 20091201 10100331 3 1234567

1234 20100401 99991231 1 1234567

Now, I want to read from this hashed table the emplstatus on 22 feb 2010.

My problem is, that I can not specify exact keys, so can not read data via the abap READ statement.

I use LOOP AT.... WHERE EMPLOYEE = 1234 AND date LE dateto and date GE datefrom.

However, this takes a long time for hash tables (tha hash algorithm is not used). The key for the table is now employee, datefrom dateto (3 fields).

How can I improve read performance? My idea is to change the table to sorted table type.

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
547

Hi mate.

Instead of LOOPing into the internal table, please have a look at PROVIDE statement.

For example:


" assume the hashed table has name 't_itab',
" and there's a structure of the same type of the header (if any)
" of t_itab, named 's_itab'.
data: flag(1) type c.
provide fields *
  from t_itab
  into s_itab
  valid flag
  bounds datefrom and dateto
  between '20091115' and '20100101'.   "or whatever the date limits are

  if flag is not initial.
    write: / 'Valid record for following values:'
    write: / s_itab-employee,
             s_itab-datefrom,
             s_itab-dateto,
             s_itab-emplstatus,
             s_itab-job.
  endif.

endprovide.

If there are gaps among dates in your internal table, and you want the PROVIDE..ENDPROVIDE loop to display them as well, add the clause "INCLUDING GAPS" in the PROVIDE statement, and then evaluate variable 'flag' to 'IS INITIAL'.

I hope this helps. Kind regards,

Alvaro

I have created a hashed table, containing HR data. The records are time dependent.

For example:

Employee datefrom dateto emplstatus job

1234 20091101 20091130 2 1234567

1234 20091201 10100331 3 1234567

1234 20100401 99991231 1 1234567

Now, I want to read from this hashed table the emplstatus on 22 feb 2010.

My problem is, that I can not specify exact keys, so can not read data via the abap READ statement.

I use LOOP AT.... WHERE EMPLOYEE = 1234 AND date LE dateto and date GE datefrom.

However, this takes a long time for hash tables (tha hash algorithm is not used). The key for the table is now employee, datefrom dateto (3 fields).

How can I improve read performance? My idea is to change the table to sorted table type.

2 REPLIES 2
Read only

Former Member
0 Likes
548

Hi mate.

Instead of LOOPing into the internal table, please have a look at PROVIDE statement.

For example:


" assume the hashed table has name 't_itab',
" and there's a structure of the same type of the header (if any)
" of t_itab, named 's_itab'.
data: flag(1) type c.
provide fields *
  from t_itab
  into s_itab
  valid flag
  bounds datefrom and dateto
  between '20091115' and '20100101'.   "or whatever the date limits are

  if flag is not initial.
    write: / 'Valid record for following values:'
    write: / s_itab-employee,
             s_itab-datefrom,
             s_itab-dateto,
             s_itab-emplstatus,
             s_itab-job.
  endif.

endprovide.

If there are gaps among dates in your internal table, and you want the PROVIDE..ENDPROVIDE loop to display them as well, add the clause "INCLUDING GAPS" in the PROVIDE statement, and then evaluate variable 'flag' to 'IS INITIAL'.

I hope this helps. Kind regards,

Alvaro

Read only

0 Likes
547

Thank you fot the response.

I doubt that this will speed up my READ, as it is still looping over the whole internal table.

Also , My date range is not known, only a date that has to be in the range of 1 of te records.

I have solved this by using SORTED tables and small package size (in BW transformation) and not use HASHED tables.