Call Transaction updates

[Former Member]

Hi ,

Can you tell me the difference between Synchronous/Asynchronous and Local Updates in call transaction method.

[Former Member]

hi

good

Asynchronous Update – The program does not wait for the work process to finish the update. Commit Work.

Synchronous Update – The program wait for the work process to finish the update. Commit Work and Wait.

Asynchronous updating. In this mode, the called transaction does not wait for any updates it produces to be completed. It simply passes the updates to the SAP update service. Asynchronous processing therefore usually results in faster execution of your data transfer program.

Asynchronous processing is NOT recommended for processing any larger amount of data. This is because the called transaction receives no completion message from the update module in asynchronous updating. The calling data transfer program, in turn, cannot determine whether a called transaction ended with a successful update of the database or not.

If you use asynchronous updating, then you will need to use the update management facility (Transaction SM12) to check whether updates have been terminated abnormally during session processing. Error analysis and recovery is less convenient than with synchronous updating.

Synchronous updating. In this mode, the called transaction waits for any updates that it produces to be completed. Execution is slower than with asynchronous updating because called transactions wait for updating to be completed. However, the called transaction is able to return any update error message that occurs to your program. It is much easier for you to analyze and recover from errors.

DataBase Commit:

This statement will apply any outstanding database updates and wait until they have actually been put on the database before proceeding to the next statement.

An ordinary commit work will initiate the process to update the databases in a separate task and will press on in your abap.

COMMIT WORK: ( Asynchronous)

Your program does not wait for any acknowledgement. it just start executing the next statment after COMMIT WORK.

thanks

mrutyun^

[Former Member]

Hi,

check the information:

http://help.sap.com/saphelp_nw04s/helpdata/en/e5/de86e735cd11d3acb00000e83539c3/content.htm

Hope this info will help you.

Rewards points if helpful.

With Regards,

K K V

[Former Member]

CALL TRANSACTION <transaction code>

USING <bdc internal table>

MODE <display mode>

UPDATE <update mode>

MESSAGES INTO <mssg int. table>.

<display mode> <update mode>

A: display all S: synchronous

E: display errors only A: asynchronous

N: no display

In the “CALL TRANSACTION USING” statement, you can specify the update mode as synchronous or asynchronous. To restate the difference:

Synchronous updating indicates that an update is completed for the transaction before processing returns to the “calling” program.

Asynchronous updating indicates that processing returns to the “calling” program immediately after the transaction is completed, even before the update is completed.

The difference in these update modes creates a tradeoff between the execution speed and the meaning of the return code.

With respect to the execution speed:

Synchronous updating is slower than asynchronous updating because processing does not return to the “calling” program until the update is complete.

Remember that the update mode when processing batch input sessions is always synchronous.

With respect to the meaning of the return code:

The return code (SY-SUBRC) after synchronous updating indicates the success or failure of the actual update. The return code after asynchronous updating only indicates the success or failure of the transaction, not the update.

[Former Member]

hi

good

Asynchronous Update – The program does not wait for the work process to finish the update. Commit Work.

Synchronous Update – The program wait for the work process to finish the update. Commit Work and Wait.

Asynchronous updating. In this mode, the called transaction does not wait for any updates it produces to be completed. It simply passes the updates to the SAP update service. Asynchronous processing therefore usually results in faster execution of your data transfer program.

Asynchronous processing is NOT recommended for processing any larger amount of data. This is because the called transaction receives no completion message from the update module in asynchronous updating. The calling data transfer program, in turn, cannot determine whether a called transaction ended with a successful update of the database or not.

If you use asynchronous updating, then you will need to use the update management facility (Transaction SM12) to check whether updates have been terminated abnormally during session processing. Error analysis and recovery is less convenient than with synchronous updating.

Synchronous updating. In this mode, the called transaction waits for any updates that it produces to be completed. Execution is slower than with asynchronous updating because called transactions wait for updating to be completed. However, the called transaction is able to return any update error message that occurs to your program. It is much easier for you to analyze and recover from errors.

DataBase Commit:

This statement will apply any outstanding database updates and wait until they have actually been put on the database before proceeding to the next statement.

An ordinary commit work will initiate the process to update the databases in a separate task and will press on in your abap.

COMMIT WORK: ( Asynchronous)

Your program does not wait for any acknowledgement. it just start executing the next statment after COMMIT WORK.

thanks

mrutyun^

[Former Member]

Hi guys ,

what abou local update.can any one explain me regarding this.

Thanks ,

Lee

[Former Member]

Any help on the Local update...

Any one plz answer my Question.

Regards,

Lee

[Former Member]

Hi,

<u><b>Local Update</b></u>

In a local update, the update program is run by the same work process that processed the request. The dialog user has to wait for the update to finish before entering further data. This kind of update is useful when you want to reduce the amount of access to the database. The disadvantage of local updates is their parallel nature. The updates can be processed by many different work processes, unlike asynchronous or synchronous update, where the update is serialized due to the fact that there are fewer update work processes (and maybe only one).

You switch to local update using the ABAP statement SET UPDATE TASK LOCAL. This statement sets a “local update switch”. When it is set, the system interprets CALL FUNCTION IN UPDATE TASK as a request for local update. The update is processed in the same work process as the dialog step containing the COMMIT WORK. The transaction waits for the update to finish before continuing.

As an example, suppose you have a program that uses asynchronous update that you normally run in dialog mode. However, this time you want to run it in the background. Since the system response time is irrelevant when you are running the program in the background, and you only want the program to continue processing when the update has actually finished, you can set the

SET UPDATE TASK LOCAL switch in the program. You can then use a system variable to check at runtime whether the program is currently running in the background.

By default, the local update switch is not set, and it is reset after each COMMIT WORK or ROLLBACK WORK. You therefore need to include a SET UPDATE TASK LOCAL statement at the beginning of each SAP LUW. If you reset data within the local update, the ROLLBACK WORK statement applies to both the

dialog and the update part of the transaction, since no new SAP LUW is started for the update.

Regards,

Bhaskar