Problem with calling function module in update task

[Former Member]

Hello Friends,

I have a situation where I am calling a FM in update task say CALL FUNCTION 'ZABCD' IN UPDATE TASK.

Inside that FM I am inserting records to a custom table say 'ZAAA' from a internal table 'ZBBB'.

Situation is like , when I am executing my report this FM ZABCD is triggered and it will keep the record in ZAAA from ZBBB and wait for a commit.

But due to some other functionality I have to change the record again and now my internal table ZBBB has some other value and with this value ZAAA is updated and waits for commit.

But when the commit triggers it gives a dump since the update task FM does not recognizing which record has to be updated. But I want to update the latest record.

Even I cannot refresh my internal table ZBBB since it may have several records and I am interested to change only one record. I want a functionality such that after commit it should update the custom table with all the records and modify the old record with the new one which I have changed recently.

Please help me how to achieve this functionality.

Hope you understood the issue.

Regards,

Harjeet

[asik_shameem]

Hello Harjeet,

Before updating the second time from the internal table ZBBB to ZAAA, ROLLBACK WORK. So the data which is updated first time are release back from the data base. It is something like below.

" Insert internal table ZBBB to database table ZAAA - First time

IF <any changes in the internal table ZBBB>.

  ROLLBACK WORK.  " Here records updated in ZAAA are releases back

  " Insert internal table ZBBB to database table ZAAA again - Second time

ENDIF.

[Former Member]

Hi Harjeet,

Before anybody comes up with obvious but silly solutions like <em>changing your update module to use [modify|http://help.sap.com/abapdocu_70/en/ABAPMODIFY_DBTAB.htm] instead of [insert|http://help.sap.com/abapdocu_70/en/ABAPINSERT_DBTAB.htm]</em> or <em>replacing your multiple [call function .. in update task|http://help.sap.com/abapdocu_70/en/ABAPCALL_FUNCTION_UPDATE.htm] with one [perform .. on commit|http://help.sap.com/abapdocu_70/en/ABAPPERFORM_SUBR.htm]</em> I'd say read up a little on SAP [transaction/LUW|http://help.sap.com/saphelp_nw04/helpdata/en/41/7af4b6a79e11d1950f0000e82de14a/frameset.htm] concept.

You should call your update function module once after you've gathered all the data you need and the input data has been checked. From an design and performance perspective anything else is most likely not acceptable (exceptions might exist in cases where you control some parts of the coding but not all).

Cheers, harald

<em>Edited by: Harald Boeing on Apr 11, 2010 3:34 PM:</em>

Wow, didn't imagine that there's even more silly ways than I could think of. Please don't use a [rollback work|http://help.sap.com/abapdocu_70/en/ABAPROLLBACK.htm]; looking at the help it should be obvious why, but the gist is <em>the statement is not supposed to be a workaround for poor application design</em>.

[Former Member]

Please check the below points.

1. Update the database table only once at the end of the function module. Till that time, just modify and update your internal table only.

2. Since it is a function module, it should act independently. So it is suggested to use COMMIT at the end of the function module only.

3. Try to use ROLLBACK or COMMIT before using the next UPDATE.

4. If you are not sure about any UPDATE which is already occurred, then use the concept of ENQUEUE database table, and if it is successful, then only use UPDATE and then DEQUEUE.

Also check the other points which are already suggested by other members.

[Former Member]

Hello All,

Thanks for your response. But I would like to mention here that we should not use COMMIT and ROLLBACK work inside the loop due to performance issues and I will not use the same in my program.

Also I found the answer myself, it can be done by using PERFORM f_xyz ON COMMIT.

Inside this f_xyz I am calling my function module directly without using update task.

This will update the final values and will not consider the previous records, so no need of roll back work.

I hope it helps you as well.

Regards,

Harjeet