Implicit commit does not seem to trigger update task function module?

[Former Member]

Hi all,

I have a module which updates certain logging information in a DB-table. This logging needs to happen always, even when the program itself does no other DB-updates.

In order to avoid dumps because rapid consecutive updates from different program executions collide because a physical lock is set at the moment of executing the insert statement, I decided to move the update logic into an update task function module.

If I trigger the update from a report the update only happens with an explicit commit work at the end of the report.

If I do not include an explicit commit work the following happens according DB trace:

• tables VBMOD, VBDATA etc are updated when the function is executed.
• implicit commit work is executed
• the date in VBMOD, VBDATA etc is deleted
• but: No actual DB update is executed

How can I make sure that the actual DB update happens even with only an implicit commit.

Thanks for any suggestions!

Marcel Hesen

[Ashg1402]

Hi,

  If you are using standard function module for update then check that their will be field for commit.

It is given as a flag parameter. Check for the field 'COMMIT' .

Which function module are you using.?

[Clemenss]

Hi Marcel,

this is the SAP logic: Functions called in update task are only executed after explicit COMMIT WORK. An implicit commit. will never execute update task functions or forms.

Probably you should work on the lock logic: There is the IV_WAIT parameter for every enqueue function.Rapid consecutive updates from different program executions can be handled by this,

That means: Enqueue (lock) before doing a dialog update (No update task). Dequeue after UPDATE. Other processes will have to wait for the time of the update and dumps will not happen

Regards Clemens

[michael_kozlowski]

This message was moderated.

[Former Member]

Hi all,

Big thanks for your quick answers and confirming my expectation on the implicit commit.

The problem is that I have multiple programs updating the exact same record in a custom table (@Ashish: No std module with commit parameter). (with identical information but unknowingly of eachother's updates). I do not mind the multiple updates, but my original implementation (direct update in the program itself) resulted in physical locks which lasted so long that there was another program kicking in and trying to update the same record.

My initial thought was to fix this by NOT creating a physical lock but moving the actual update into a self developed specific update task FM. Unfortunately, the updates also need to happen in programs lacking an explicit commit.

@Clement put me on an interesting other angle: if the updates are identical than a lock operation would work fine, as the update could be skipped in that case...

Thanks Clemens!

mh