Skip to Content
Former Member
Apr 14, 2007 at 06:28 PM

Where/how would you add the actual DB update to BCALV_EDIT_03?


BCALV_EDIT_03 provides an excellent example to learn about (steal) the correct techniques for presenting and processing an ALV with some (not all!) editable columns.

It does not, however, actually show you where/how to handle the actual call for the database update that should result from a user changing data in a way that meets all validation criteria. (Assume for the sake of discussion that you're updating a custom Z table from the editable ALV in BCALV_EDIT_03 - this will avoid discussion of extraneous matters such as BAPI's, BDC's, etc.)

So here's what I think.

The "handle_data_changed" method of BCALV_EDIT_03 looks like this:

class lcl_event_receiver implementation.
  method handle_data_changed.

    data: ls_good type lvc_s_modi.

    error_in_data = space.

    loop at er_data_changed->mt_good_cells into ls_good.
      case ls_good-fieldname.
* check if column PLANETYPE of this row was changed
        when 'PLANETYPE'.
          call method check_planetype
                    ps_good_planetype = ls_good
                    pr_data_changed   = er_data_changed.

* check if column SEATSOCC of this row was changed
        when 'SEATSOCC'.
          call method check_seatsocc
                    ps_good         = ls_good
                    pr_data_changed = er_data_changed.

*§7.Display application log if an error has occured.
    if error_in_data eq 'X'.
       call method er_data_changed->display_protocol.


I personally would change the last "if" in this method to the following:

if error_in_data eq 'X'.

call method er_data_changed->display_protocol.


loop at er_data_changed->mt_good_cells into ls_good.

update itab gt_outtab_new "note: this is pseudo-code, not real code



In particular, since we know all data is good if we're in the else, we can loop one more time thru er_data_changed->mt_good_cells and use the rowid and fieldname to update an itab called "gt_outtab_new" (with the same row structure as the original itab "gt_outtab " used to populate the ALV.)

Then, when the user indicates he or she wants to "save", we simply loop through gt_outtab_new and update the actual database table from the wa (or header) of gt_outtab_new. (We are safe to do this because the itab gt_outtab_new will always contain the latest and greatest changed data that have passed all validation checks.)

Is this basically the correct approach?

If so, please confirm.

If not, please say "why not" and briefly indicate correct approach.

Thanks very much in advance.