best practice for handling changed data in ALV grid

[ennowulff]

Hi there!

I often use the ALV grid in my programs. But mostly I use it for displaying data. The more I have to deal with the event DATA_CHANGED of CL_GUI_ALV_GRID the more I get annoyed because I always begin from scratch.

Each time I am not sure about how to deal with different actions.

Do you have a best practice template or some information about when to do what?

• First process deleted_lines or inserted_lines? Does it matter after all?
• How to deal with deleted or inserted lines according to the internal data table?
• How to react if a database table is the base?
• Use a CUD (Create - Update - Delete) flag in the table to mark inserted, modified and deleted lines?
• Or use three different tables with DELETED, INSERTED or MODIFIED entries?
• How to deal with the index? when to use ROW_ID when TABIX?
• Automatically check duplicate keys?
• How to deal with MT_GOOD_CELLS, MT_MOD_CELLS and MT_MOD_ROWS?
• what to keep in mind if using MC_EVT_ENTER or MC_EVT_MODIFIED?
• How to check if really every action works correctly (copying lines, appending lines, delete and copy in one step, ...)?

Some examples for some tricky actions in the grid:

Copying lines

In this case the MT_INSERTED_ROWS is filled and tells on which index the line has been copied.

Additionally the copied values are given in MT_GOOD_CELLS which need to be transferred.

If you do some validation checks here the user will get annoyed because of course the key is duplicate now (must be changed after copying lines), maybe dates are invalid (date in the past).

Checking and displaying key fields

Key fields normally should not be changed. If there are entries from the database, then they cannot be changed.

If there are new inserted entries I could change the key values as long as the data as not been saved.

Key fields must be set to read-only...

additional checks

after having inserted or changed data, I would like to validate the entries, like

• email adress invalid
• if FIELD_A is initial FIELD_B must be filled out
• ...

Checks, that might be done when checking data and not of necessity when directly entered the field value. For example at USER_COMMAND &CHECK or after all entries have been updated.

In this case I might not have the protocol object and therefore I cannot display errors or warnings in this protocol. If I force to use a protocol object, it is not properly filled so that I cannot define a field or line where the error occured.

I am glad about any hints about how to generally deal with DATA_CHANGED.

Cheers
~Enno

johann.fleitner2 28f4b37a40894f18a22abc696b8154f4 maybe? 🙂

[ennowulff]

I got some hints (thanks pjl 😄 )...

1. never ever touch the internal data table and modify data directly.
2. All changes made to the table are in ER_DATA_CHANGED->MP_MOD_ROWS
3. If you want to set additional data then use ER_DATA_CHANGED->MODIFY_CELL
4. If you don't comply to the value a user edited, then throw an error using ER_DATA_CHANGED->ADD_PROTOCOL_ENTRY
5. you don't have to decide wheter you chose MC_EVT_MODIFIED or MC_EVT_ENTER. If done right, the grid behaves the same.

There is one weird thing: If you change an entry using MODIFY_CELL, a new entry will be added to MT_GOOD_CELLS WITHOUT A VALUE!! That's weird but okay; the entry will be updated in MP_MOD_ROWS.

[Föß]

Hi,

I have done a lot with editable ALV GRID, but to be honest – many years ago. But I try to tell you my findings (as far as I remember).

Events DATA_CHANGED / DATA_CHANGED_FINISHED

I use the DATA_CHANGED event to get the updated and inserted data. I have always my own “GOOD_CELLS” in my developments, so after some additional checks (valid values, duprec) in the DATA_CHANGED event, I move the MOD_CELLS of the grid to a global GOOD_CELLS table in my development. I use the DATA_CHANGED_FINISHED to update the internal data table based on my own GOOD_CELLS table.

Delete, Insert, Copy

I always define my own functions for delete, insert or copy. I don’t use the standard alv functions because I want to handle as much as possible in my own handler class.

The handler class looks like this:

• Get selected rows from alv grid class (for delete and copy)
• For Delete: Delete records from internal table & from GOOD_CELLS
• Similar for Insert (Insert to internal table)
• Refresh grid data

Save / Process changes

Like the delete/insert function, I use my own “SAVE” function.

• Based on a combination of the internal table and the GOOD_CELLS (=all changed cells/lines), I create dynamic UPDATE/INSERT/DELETES for the db changes.

Maybe it's not the best way to use the alv grid class, but it worked for me. - If you want to go in this direction, I would have to check my developments to give you more details.

lgf

[ennowulff]

Thanks for your answer!

I often heard that own insert and delete functions are used. Meanwhile I think it is because the implemented behaviour has not been understood. Thanks to Peter I understood today how this works.

The dynamic update/insert/ delete seems to be the hardest part... 😄