MODIFY Table in OO Context

[former_member379910]

Hi!

I'm trying to modify an internal table which is a public attribute of a class. I'm always getting a sy-subrc 4.

Here is my code to describe my problem:

MODIFY TABLE go_instance->gt_table FROM <table>.

The datatype of <table> is correct. When I assign with READ TABLE and change the field, it works... but not via MODIFY.

Is the MODIFY in OO-context not allowed?

Thanks in advance!

Daniel

[Former Member]

Hi

MODIFY is allowed in OO.

MODIFY TABLE is used to change a single row of the table.

But since you are using a table to modify it means you must be trying to change more than one row.

If so then drop the TABLE.

If you want to modify a single row use INDEX <tabix> at the end.

Pushpraj

[former_member379910]

Hi Pushpraj!

Sorry, my fault. The field-symbol <table> is a single row. I only named it "table" to show it's the same type.

I cannot use INDEX because I don't know the index of the go_instance->gt_table at this time.

Maybe this new sample will help:

LOOP AT it_sim ASSIGNING <sim_kls>.
  MODIFY TABLE go_instance->gt_sim FROM <sim_kls>. "*sy-subrc 4*
ENDLOOP.

Edited by: DanielS on Dec 9, 2009 10:27 AM

[Former Member]

Is the key of both tables unique?

are you defining a key?

[former_member379910]

Hi all!

Arshad, the index of it_sim an go_instance->gt_sim aren't the same. So

INDEX sy-tabix

doesn't work. it_sim is an extract of gt_sim.

Ramiro, yes it_sim and gt_sim are same type with same key.

Thanks!

[Sm1tje]

Sure it is possible since this probably has nothing to do with OO Context. II guess that the MODIFY statement is not working since no suitable line was found to be modified. Check the contents of your internal table. Maybe it is even empty, in that case it won't work either (It is not a DB table in which the MODIFY statement will change or insert lines).

[former_member379910]

Hi Micky!

It's the same type and only one field is different which is not in the key. So MODIFY has to change the entry from "EINZELTEILE" to "KIT".

Old data in table:

101 2009 024 00001 000000000000766710 TEILEART EINZELTEILE 10.000

New data in field-symbol:

101 2009 024 00001 000000000000766710 TEILEART KIT 10.000

Thanks!

[Former Member]

Halo Daniel,

LOOP AT it_sim ASSIGNING <sim_kls>.

MODIFY TABLE go_instance->gt_sim FROM <sim_kls> index sy-tabix. "sy-subrc 4

ENDLOOP.

[Former Member]

Hi Daniel,

I'm trying to modify an internal table which is a public attribute of a class.

Please consider a change for your code. Defining an attribute of a class as PUBLIC is considered bad programming style in OO-Programming. There are certain use-casses, where this is considered for performance reasons only. The addition READ-ONLY should be used for those use-cases.

This addition is solely possible in the public visibility area of a class or in an interface. It has the effect that an attribute declared using DATA is readable from an external point, but can only be changed using methods of the class or its subclasses.

Here is my code to describe my problem: MODIFY TABLE go_instance->gt_table FROM <table>.

Please add the definition of your table type next time, because this is very important for the MODIFY TABLE statement. Right now, I'm only able to guess what the problem might be. If you were able to use the INDEX addition without a syntax error, then you're probably using a STANDARD or SORTED TABLE (HASHED TABLEs don't have an index)

Also, there is a diference between:

 MODIFY go_instance->gt_table FROM <table> INDEX xyz. 

and

MODIFY TABLE go_instance->gt_table FROM <table>.

The combination "MODIFY TABLE gt_sim FROM <sim_kls> INDEX sy-tabix" is not allowed in ABAP.

With MODIFY TABLE, the line to be changed is determined by the fact that the content of the table key matches the content of the corresponding components in the wa work area. For tables with a key that is not unique, the first entry that is found is changed.

So, my guess is that you're using a STANDARD TABLE without the KEY addition. The MODIFY TABLE will thus use a standard key, which is basically the table-line. And since the full lines are different, then the MODIFY TABLE should fail to find the line. My recommendation would be to define "gt_table" as SORTED TABLE with the proper key.

HTH,

Hristo

[former_member379910]

Hi Hristo!

Thanks for the very qualified answer!

I know that defining public attributes isn't a good programming style. But in my case it's ok

Now to my issue with the MODIFY.

The table type is a standard table with the following "db" keys: MANDT;JAHR;VERSION;ORGA;MATNR;KLASSE

Now I tried to define the table type as a sorted table - with "default" key. => Result: same error

Then I listed the key components explicitly, same key (MANDT;JAHR;VERSION;ORGA;MATNR;KLASSE) => Result: it works....

Ok, it has something to do with the key... but its the same now.. ... If someone could explain this it would be great...

Thanks for all.

Best wishes

Daniel

[Former Member]

Hi Daniel,

 Ok, it has something to do with the key... but its the same now..  ... If someone could explain this it would be great... 

quite simple

\[ UNIQUE | NON-UNIQUE ] DEFAULT KEY
This declares the fields of the default key as the key fields. If you have a structured line type, the standard key is build from all columns of the internal table that have a character-type type (c, d, t, n, x, string, xstring). Internal tables with a nested row structure have a standard key built by linearization of the row structure. At elementary row types, the standard key is the row itself. Elementary tables with an internal table as row type have an empty standard key.
http://help.sap.com/saphelp_nw70/helpdata/en/fc/eb366d358411d1829f0000e829fbfe/frameset.htm

one more thing:

The table type is a standard table with the following "db" keys: MANDT;JAHR;VERSION;ORGA;MATNR;KLASSE

Please note that the primary key of the DB-table does not influence the key of your internal table. When you define an internal table, then you can define your own key. You are actually very encouraged to do so, because otherwise the DEFAULT KEY is used. If the table type of the internal table is SORTED, then the data from the DB is automatically sorted to match the internal table sorting.

I strongly recommend to use SORTED/HASHED tables.

(SORTED can have UNIQUE / NON-UNIQUE KEY - sorting according to key is performed. The key is read from left-to-right, thus not all fields of the key must be specified to enforce a binary search)

(HASHED can have UNIQUE KEY only - sorting is irrelevant, all fields of the key must be specified)

Thus, STANDARD tables are to be used only for some special cases (e.g.):

- you can not sort technically (e.g. JANUARY, FEBRUARY, MARCH, APRIL is wanted, instead of the technical sorting APRIL, FEBRUARY, JANUARY, MARCH)

- the sequence is relevant (e.g. stack-implementations (LIFO-principle) or queue implementations (FIFO-principle))

So, if you dont have one of those use-cases, then please always use SORTED/HASHED tables.

Kind regards,

Hristo

[former_member379910]

Hi Hristo!

Thanks. I'm impressed! Very good and helpful answer!

Kind regards,

Daniel