How does SAP permit "indirect" commits within 'in update task" functions?

[Former Member]

As everyone knows, if you code an explicit commit or a call to BAPI_TRANSACTION_COMMIT inside a user exit or implicit enhancment within an SAP "posting" function module ("FM") that SAP has called "in update task", you will get a short-dump.

But I need someone to explain how and why SAP is allowing the following sequence of events to occur.

In the SAP function group V45U, there is an FM RV_SALES_DOCUMENT_ADD, and this FM is called "in update task" from the beleg_sichern form of the core SAP Sales Doc progtam SAPLMV45A.

At the end of the FM RV_SALES_DOCUMENT_ADD, I've coded an implicit enhancement which winds up calling a custom FM of my own in a custom function group. (This custom FM group is NOT called "in update task".)

Inside this custom FM, I do the following:

1) I insert a record into a custom transparent table (but of course do not commit it, because that would cause a short-dump.)

2) Later on, inside the same custom FM, I call SAP's FM MASTER_IDOC_DISTRIBUTE to send an IDOC, and when I get the IDOC number back from this FM, I successfully update the record that I've previously inserted into the custom table. (In particular, I update the previously inserted record with the IDOC number I get back from SAP.)

So how is it possible that I can update a record in a transparent table when this record hasn't yet been committed?

Here in the office, we're convinced that it must be because an "indirect" commit occurs during the SAP IDOC FM - either an explicit commit which SAP issues, or an implict commit at the end of this function.

Because if such an explicit or implict commit does occur within the SAP IDOC FM, it would of course commit the record that I previously inserted into the custom table, and that would explain why I can update this record with the IDOC number I get back from the SAP FM.

Can someone confirm that this is in fact what's happening, or set us straight as to how and when and why the inserted record is getting committed prior to the update of this record, even though this commit is taking place inside the larger context of an SAP "posting" FM that's called "in update task"?

[kesavadas_thekkillath]

Hi,

how and when and why the inserted record is getting committed prior to the update of this record, even though this commit is taking place inside the larger context of an SAP "posting" FM that's called "in update task"?

I insert a record into a custom transparent table (but of course do not commit it,

After the DB operation INSERT , in some cases implicit commit might happen.

Please check the second & third point in link:[Implicit Database Commits|http://help.sap.com/saphelp_nw70/helpdata/EN/41/7af4bca79e11d1950f0000e82de14a/content.htm]

For solution may be you should have a look into [call function in background task as seperate unit|http://help.sap.com/saphelp_nw04/helpdata/en/8f/53b67ad30be445b0ccc968d69bc6ff/content.htm].

Keshav

[former_member181923]

Hi Keshav

Thanks for taking the time to respond, but as you can see from Max's and Suha's replies, the answer doesn't have anything to do with implicit commits.

It has to do with the fact that SAP lets an LUW check the rollback area for previous changes made within the same LUW.

Best

djh

[SuhaSaha]

Hello David,

2) Later on, inside the same custom FM, I call SAP's FM MASTER_IDOC_DISTRIBUTE to send an IDOC, and when I get the IDOC number back from this FM, I successfully update the record that I've previously inserted into the custom table. (In particular, I update the previously inserted record with the IDOC number I get back from SAP.)

This is because all the changes are made inside the same Database LUW. Imo there is no implicit /explicit database commit involved here!

Check this code snippet:

DATA scarr_wa TYPE scarr.

scarr_wa-carrid   = 'FF'.
scarr_wa-carrname = 'Funny Flyers'.
scarr_wa-currcode = 'EUR'.
scarr_wa-url      = 'http://www.funnyfly.com'.

* Step 1: Add the data to the table
INSERT into scarr values scarr_wa.
CHECK sy-subrc = 0.

* Step 2: Select the "inserted" data from the table
SELECT SINGLE * FROM scarr INTO scarr_wa WHERE carrid = 'FF'.
CHECK sy-subrc = 0.

scarr_wa-url = 'http://www.funfly.com'. "URL changed

* Step 3: Modify the data from the table
MODIFY scarr FROM scarr_wa.
CHECK sy-subrc = 0.

After Step 1: Go & check SE16n, you'll get a reference of the new entry there.

After Step 3: Go & check SE16n, the data has been updated.

Now issue a database rollback, you wont get a reference to the CARRID 'FF'. Since all the changes were part of the

same Database LUW, the rollback cancels all the DB operations.

Hope i'm clear.

BR,

Suhas

[Former Member]

Hi

Your fm is not called in update task, but it called by a fm working in update task

All fms called in update task process belonog to the same LUW, an implicit commit will be at the end of the LUW jusrb as all we know.

Now see this simple report:

TABLES ZMAX_MAX.

DELETE FROM ZMAX_MAX WHERE FIELD1 = 'A'.
WRITE SY-SUBRC.

ZMAX_MAX-FIELD1 = 'A'.

INSERT ZMAX_MAX.

SELECT SINGLE *
  FROM ZMAX_MAX WHERE FIELD1 = 'A'.
WRITE SY-SUBRC.

ZMAX_MAX-FIELD2 = 'B'.
UPDATE ZMAX_MAX.
WRITE SY-SUBRC.

The report doesn'r working in update task, but anyway the COMMIT will be called at the end, but the output of my report is:

4 0 0

4 is for the INSERT, that means if I run the report again, the output will be:

0 0 0

So no COMMIT is called in the report, but I can do several modification for the same report before the COMMIT and the next modification works on the data updated by the previous STATAMENT.

So I can suppose all modifications made in the same LUW are immediatelly available after doing them (I mean after INSERT, UPDATE or MODIFY), because they belong to the same db luw just as it's explained in the link of Keshav.

It means all modifications are placed in rollback area, so all modifications can be available for the program (generally for the same LUW),

The commit statament releaes the rollback area and store them in DB

Max

[former_member181923]

Hi Max and Suhas -

Thanks for the definitive answers - very much appreciated.

I honestly wasn't aware that inside the same LUW, SAP lets the LUW check the rollback area for previous changes within the same LUW.

Best

djh

[SergioFerrari]

Sorry to use this post but I want to invite you Max to attend to the SAP Inside Track 2011 in Milan [http://wiki.sdn.sap.com/wiki/display/events/SAPInsideTrackMilan2011|http://wiki.sdn.sap.com/wiki/display/events/SAPInsideTrackMilan2011].

Hope to see you there.

Sergio