Equivalent of "APPEND INITIAL ASSIGNING" for a hashed itab

[Former Member]

OK -

We all know that we don't append wa's to itabs.

Instead, we "append initial line assigning <fs>" and then fillup <fs>,

But what about when I want to use a hashed itab to do an automatic de-dedup (like SAP does "under the covers" with COLLECT.)?

Putting field-symbols aside for the moment, I would code:

INSERT wa INTO TABLE itab

and let this insert fail on dup key condition.

So what is the equivalent of this statement with a field-symbol?

I've looked at the "insert result" section of the on-line documentation but I have to confess I don't understand it?

Remember, we want the insert to fail if the key is already present in the hashed itab.

[naimesh_patel]

I guess SY-SUBRC gets 4 when we try to insert the data with the same key.

types: begin of ty_tab,
       num   type i,
       text  type char10,
       end   of ty_Tab.

data: t_tab type hashed table of ty_Tab WITH UNIQUE KEY num,
      wa_tab like line of t_Tab.

insert wa_tab into table t_tab.
insert wa_tab into table t_tab.
if sy-subrc = 4.
  write: 'Second insert Failed'.
endif.

I got the output " Second Insert Failed"

Regards,

Naimesh Patel

[former_member181923]

Thanks but that wasn't the question - not even close to the question.

We WANT to get the bad sy-subrc and we WANT to ignore it - that's how you automatically dedup using a hashed itab.

The question is: how do we insert using a field-symbol and still make sure that we get the same dup key error ???????

[RichHeilman]

Well, in that case, I would say that you would not use a field symbol to do this. You could, but it would be a little useless, and redundant.

types: begin of t_foo,
        field1 type char2,
        field2 type char2,
        field3 type char2,
        field4 type i,
       end of t_foo.

data: lt_foo type HASHED TABLE OF t_foo
               WITH UNIQUE KEY field1 field2 field3.
data: ls_foo like line of lt_foo.
FIELD-SYMBOLS: <ls_foo> like LINE OF lt_foo.

* Must assign it to use it.
assign ls_foo to <ls_foo>.

clear <ls_foo>.
<ls_foo>-field1 = 'AB'.
<ls_foo>-field2 = 'CD'.
<ls_foo>-field3 = 'EF'.
<ls_foo>-field4 = '2'.
insert <ls_foo> into table lt_foo.

clear <ls_foo>.
<ls_foo>-field1 = 'AB'.
<ls_foo>-field2 = 'CD'.
<ls_foo>-field3 = 'EF'.
<ls_foo>-field4 = '2'.
insert <ls_foo> into table lt_foo.
If sy-subrc <> 0.
   write:/ 'Hey!!! duplicate key here'.
endif.

Also, remember, lets not say that you ALWAYS have to use field symbols to access an internal table. You only get the benefit when dealing with internal tables with very large datasets. So if you itab has less than 10 or so rows, you will not see a performance poost by using field symbols.

Regards,

Rich Heilman

[former_member181923]

Hey Rich -

Aha!

That's exactly the answer I was looking for.

It is redundant to use a field symbol, because we still have to use the wa.

And as you point out, it isn't always the case that fs's do better than wa's.

I think you missed the session with Horst and Thomas (Thomas J stopped by also) in the clubhouse this past tech ed.

They all said what I've been saying for two years now - EVERY golden-plated ABAP best-practices statement coming out of Walldorf must be qualified - otherwise there are more than enough folks who will insist on applying it universally.

Best as always.

djh

[RichHeilman]

As far as using the "RESULT" extensions of the INSERT statement, you can use the ASSIGNING extension to give you direct access to the line which you just inserted into the table. The field symbol will only be assigned if the INSERT has been successful

types: begin of t_foo,
        field1 type char2,
        field2 type char2,
        field3 type char2,
        field4 type i,
       end of t_foo.

data: lt_foo type HASHED TABLE OF t_foo
               WITH UNIQUE KEY field1 field2 field3.
data: ls_foo like line of lt_foo.
FIELD-SYMBOLS: <ls_foo> like LINE OF lt_foo.

* add a line to the itab
clear ls_foo.
ls_foo-field1 = 'AB'.
ls_foo-field2 = 'CD'.
ls_foo-field3 = 'EF'.
ls_foo-field4 = '2'.
insert ls_foo into table lt_foo  ASSIGNING <ls_foo>.

* You now have direct access to that line of the internal table
* regardless of where it may be, index-wise
write:/ <ls_foo>-field1, <ls_foo>-field2, <ls_foo>-field3, <ls_foo>-field4.

* Now try to add it again, this will fail
clear ls_foo.
ls_foo-field1 = 'AB'.
ls_foo-field2 = 'CD'.
ls_foo-field3 = 'EF'.
ls_foo-field4 = '3'.
insert ls_foo into table lt_foo ASSIGNING <ls_foo>.
If sy-subrc <> 0.
   write:/ 'Hey!!! duplicate key here'.
else.
   write:/ <ls_foo>-field1, <ls_foo>-field2, <ls_foo>-field3, <ls_foo>-field4.
endif.

Regards,

Rich Heilman

[former_member181923]

Hey Rich -

Now that's a useful tip - .... very pretty.

Thanks very much for coming back to explain the "assigning" part of the "results" syntax. I can think of a million places to use it.

Best as always

djh