Hash Table - BSIS - A test code

[Former Member]

Hi All,

I want to improve one program involving table BSIS. I thought HASH table could be good option considering the large volume of BSIS. Below is my code, any suggestion etc. Since first time I am using HASH table.

Thank you,

*********************************

REPORT ZHASHTABLE .

tables : bsis.

data irec type i.

select-options : postdate for bsis-budat,

cocode for bsis-bukrs,

hkont for bsis-hkont.

data i_bsis like bsis occurs 0 with header line.

data : tab_bsis like line of i_bsis.

data : it_bsis type hashed table of bsis with unique key BUKRS

HKONT

AUGDT

AUGBL

ZUONR

GJAHR

BELNR

BUZEI.

start-of-selection.

select * from bsis

into table it_bsis

where bukrs in cocode and hkont in hkont.

delete it_bsis where not ( budat in postdate ).

describe table it_bsis lines irec.

loop at it_bsis into tab_bsis.

move-corresponding tab_bsis to i_bsis.

append i_bsis.

clear i_bsis.

clear tab_bsis.

endloop.

loop at i_bsis.

write / i_bsis.

endloop.

[Former Member]

I think using hashed tables is only relevant when you need to access particular entries. Since you are not doing that here, I don't see any reason for this.

I find sorted and hashed tables to be inflexible, so I normally use standard tables, sort them any way I need and then use a binary search to retrieve records.

Rob

[Former Member]

Hi

Use the Standard tables only

Why you need all the fields in BSIS table

Declare internal table with the required fields only in the order of sequence they are in the table

fetch them accordingly

data : begine of it_bsis occurs 0,

f1,

f2,

end of it_bsis.

start-of-selection.

select f1 f2 from bsis

into table it_bsis

where

bukrs in cocode and

hkont in hkont and

budat in postdate and

gjahr = '2007'.

You can hardcode the GJAHR field for the year you wants to fetch data

This will not take much time

Regards

Anji

[Former Member]

The problem is the program is failing for either DBIF_RSQL error or TSV_TNEW_PAGE_ALLOC_FAILED.

[Former Member]

1. Instead of hardcoding as suggested by Anji, pass the year as a selection-screen parameter.. this way you will avoid a maintenance issue

2. Do not use the occurs parameter.. instead declare a work area for your itab..

Arya

[Former Member]

The interesting part of it is the more parameters I add to variant more times it fails for these errors.

[Former Member]

Just be more restrictive. You're retrieving too much data. Use a less widely used account.

Rob

[Former Member]

Thank you all for your suggestions...

[Former Member]

Hi Bonny,

A hash table is only beneficial if you create a key AND are able to provide the full key. In your case, it does not look like you are accessing the table with the full key. It does not help you in your DELETE statement.

If you are deleting records from your internal table it would be better to sort by the date since that is your criteria for deletion.

But it would be better all around if you would:

- create a table with only fields you need rather than all fields of bsis. It takes time to pull in all the fields and memory as well.

- it is better to bring back only the records you need so your where clause should include the BUDAT in POSTDATE.

Imagine if you select a single date or a range of a week or even a month. Your Select will pull back everything in the company code and account number which could be tens or hundreds of thousands of records and end up with only a few records. And it would do this each time regardless of your date range because you filter out unwanted dates after you've brought all those records back.

So really you need to recode your Select statement to incorporate your select options posting date. I could see this taking a very long time otherwise.

Hope this helps.

Filler

[Former Member]

Just a one doubt, can I create index as per my requirment on BSIS?

[Former Member]

It's usually a bad idea to create an index on a standard SAP table - especially just to speed up one SELECT. And that won't help with with your memory problem.

Rob