‎2016 Apr 29 4:06 AM
Hi Experts,
When I try to append a work area into a hashed table with the following syntax:
APPEND wa_hash TO it_hash
I get the error message "You cannot use explicit or implicit index operations on tables with"
But, if I use the syntax SELECT APPENDING TABLE into a HASHED TABLE, there's no error and the program works just fine.
When I check the ABAP documentation:
"The results set is inserted into the internal table itab row-by-row; a sorting process is executed in the case of a sorted table. If INTO is used, the internal table is initialized. Previous rows remain intact if APPENDING is used."
It is said that the result set is inserted into the internal table row by row. Does this mean using SELECT APPENDING TABLE into a HASHED TABLE is actually the same as using INSERT wa_hash INTO TABLE it_hash? Then the difference of using SELECT INTO TABLE and SELECT APPENDING TABLE is that when using INTO TABLE, the internal table is first initalized.
Regards,
Suwandi C.
‎2016 Apr 29 5:35 AM
Hi,
If an internal table is declared as hashed table, it means that it has some key fields. They don't have any linear index. So when we do any insert or append, it works on index, but for hashed tables there is no such concept. As this kind of table is accessed by key not index.
Regards
Ashish
‎2016 Apr 29 5:42 AM
Funny. I always assumed that you couldn't use APPENDING INTO with a HASHED TABLE - but it seems you can. In which case, it appears that APPENDING INTO actually does the equivalent of an INSERT INTO. Perhaps it the addition SELECT .... INSERTING INTO table ... would be nicer.
For your questions though - why not try it and see?
- I've read the documentation, and to me it's not entirely clear that it works with HASHED tables - although there is mention of SORTED tables. And how about an INSERTING INTO alternative for ABAP 7.60?
‎2016 Apr 29 5:47 AM
Hi matthew,
I tried both APPEND and INSERT, it doesn't allow. Only SELECT APPENDING works.
‎2016 Apr 29 5:48 AM
‎2016 Apr 29 5:52 AM
I tried this:-
DATA: it_ekko TYPE HASHED TABLE OF ekko WITH UNIQUE KEY ebeln WITH HEADER LINE,
wa_ekko LIKE LINE OF it_ekko.
SELECT * FROM ekko APPENDING TABLE it_ekko UP TO 5 ROWS. " This worked
it_ekko-ebeln = '000000001'. " I thought it will allow append with header line but didn't work
append it_ekko to it_ekko.
wa_ekko-ebeln = '000000002'. " Same error with this too
insert wa_ekko into it_ekko.
‎2016 Apr 29 6:01 AM
First of all, the discussion is about database selections into internal tables, rather than just internal table usage. Multiple SELECT ... APPENDING TABLE ... work for HASHED tables (and SORTED), which I wasn't previously aware of. Glad to find out, though I feel a bit stupid.
Second - you can't use APPEND (the internal table operation) on a HASHED table (or a SORTED table for that matter), as it just tries to add the data to the end of the table. No-one is disputing this.
Third - to insert into a hashed table you must use. INSERT wa INTO TABLE my_hashed_table.
Fourth - don't use tables with header lines, they're obsolete and, even more importantly, ambiguous bad programming.
‎2016 Apr 29 6:07 AM
First - If you look again at the discussion, It has started with the append error.
So, its not purely about database selection, I think it is about internal table usage.
Second - I agree with append part, that's the same i tried to explain in my previous comment.
Third - My mistake for not using INSERT wa INTO TABLE my_hashed_table.
Fourth - That header line i just wanted to check that whether it's issue with keys or not. I know that it's obsolete.
‎2016 Apr 29 7:11 AM
Hmm, the documentation says:
If the results set consists of multiple rows, an internal table itab of any table type can be specified as a host variable using the escape character @ after INTO or APPENDING.
"any table type" includes hashed tables doesn't it? (In German I distinguish between "Tabellenart" (table kind) and "Tabellentyp" (table type). The table kind (standard, sorted, hashed) is a part of the table type. Unfortunately, the difference between kind and type is generally lost in translation).
the results set is inserted into the internal table itab row-by-row
Sounds like more like "insert" than "append" for me, but OK, a link to INSERT can help here.
And how about an INSERTING INTO alternative for ABAP 7.60?
Yeah, there are a lot of such additions that for historical or other reasons do not express their exact semantics (e.g. the infamous ACCEPTING DUPLICATE KEYS). But I'm afraid that will not be changed any more.