<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Diff  Sync &amp; Async database update in Application Development and Automation Discussions</title>
    <link>https://community.sap.com/t5/application-development-and-automation-discussions/diff-sync-async-database-update/m-p/2326726#M511406</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;HI,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;A href="http://fuller.mit.edu/tech/sync_asynchronous.html" target="test_blank"&gt;http://fuller.mit.edu/tech/sync_asynchronous.html&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The UPDATE addition determines the processing mode for batch input processing. You can specify a character-type object for upd. Its possible content and its effect are displayed in the following table. Without use of one of the additions UPDATE or OPTIONS FROM, the effect is the same as if upd had the content "A". &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Asynchronous update. Updates of called programs are executed in the same way as if in the COMMIT WORK statement the AND WAIT addition was not specified. &lt;/P&gt;&lt;P&gt;Synchronous processing. Updates of the called programs are executed in the same way as if in the COMMIT WORK statement the AND WAIT addition had been specified. &lt;/P&gt;&lt;P&gt;Local update. Updates of the called program are executed in such a way as if the SET UPDATE TASK LOCAL statement had been executed in it. &lt;/P&gt;&lt;P&gt;Other As for "A". &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Synchronous Update &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;In synchronous update, you do not submit an update request using CALL FUNCTION... IN UPDATE TASK. Instead, you use the ABAP statement COMMIT WORK AND WAIT. When the update is finished, control passes back to the program. Synchronous update works in the same way as bundling update requests in a subroutine (PERFORM ON COMMIT). This kind of update is useful when you want to use both asynchronous and synchronous processing without having to program the bundles in two separate ways. The following diagram illustrates the synchronous update process:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Use this type of update whenever the changed data is required immediately. For example, you may want to link SAP LUWs together where one LUW depends on the results of the previous one.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Asynchronous Update &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;A typical R/3 installation contains dialog work processes and at least one update work process. The update work processes are responsible for updating the database. When an ABAP program reaches a COMMIT WORK statement, any function modules from CALL FUNCTION... IN UPDATE TASK statements are released for processing in an update work process. The dialog process does not wait for the update to finish. This kind of update is called asynchronous update.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The following diagram shows a typical asynchronous update:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;For example, suppose a user wants to change an entry in a database table, or add a new one. He or she enters the necessary data, and then starts the update process by choosing Save. This starts the following procedure in the ABAP program:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Firstly, the program locks the database entry against other users, using the enqueue work process (or the message server in the case of a distributed system). This generates an entry in the lock table. The user is informed whether the update was successful, or whether the lock could not be set because of other users. &lt;/P&gt;&lt;P&gt;If the lock is set, the program reads the entry that is to be changed and modifies it. If the user has created a new entry, the program checks whether a record with the same key values already exists. &lt;/P&gt;&lt;P&gt;In the current dialog work process, the program calls a function module using CALL FUNCTION... IN UPDATE TASK, and this writes the change details as an entry in table VBLOG. &lt;/P&gt;&lt;P&gt;When the program is finished (maybe after further dialog steps), a COMMIT WORK statement starts the final part of the SAP LUW. The work process that is processing the current dialog step starts an update work process. &lt;/P&gt;&lt;P&gt;Based on the information passed to it from the dialog work process, the update work process reads the log entries belonging to the SAP LUW from table VBLOG. &lt;/P&gt;&lt;P&gt;The update work process passes this data to the database for updating, and analyzes the return message from the database. If the update was successful, the update work process triggers a database commit after the last database change and deletes the log entries from table VBLOG. If an error occurred, the update work process triggers a database rollback, leaves the log entries in table VBLOG, flags them as containing errors, and sends a SAPoffice message to the user, who should then inform the system administrator. &lt;/P&gt;&lt;P&gt;The corresponding entries in the lock table are reset by the update work process. &lt;/P&gt;&lt;P&gt;Asynchronous update is useful when response time from the transaction is critical, and the database updates themselves are so complex that they justify the extra system load of logging them in VBLOG. If you are running a transaction in a background work process, asynchronous update offers no advantages.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;check these thread..&lt;/P&gt;&lt;P&gt;&lt;A class="jive_macro jive_macro_message" href="https://community.sap.com/" __jive_macro_name="message" modifiedtitle="true" __default_attr="727442"&gt;&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;A class="jive_macro jive_macro_message" href="https://community.sap.com/" __jive_macro_name="message" modifiedtitle="true" __default_attr="1872225"&gt;&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;Priyanka.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Mon, 04 Jun 2007 04:07:16 GMT</pubDate>
    <dc:creator>Former Member</dc:creator>
    <dc:date>2007-06-04T04:07:16Z</dc:date>
    <item>
      <title>Diff  Sync &amp; Async database update</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/diff-sync-async-database-update/m-p/2326722#M511402</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi!&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;  Can u explain in simple words Diff  btween Sync &amp;amp; Async database update&lt;/P&gt;&lt;P&gt;  What is Database Commit&lt;/P&gt;&lt;P&gt;   Sync &amp;amp; Asyns Processing&lt;/P&gt;&lt;P&gt;  &lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;&lt;P&gt;Imran.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 02 Jun 2007 16:55:22 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/diff-sync-async-database-update/m-p/2326722#M511402</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-06-02T16:55:22Z</dc:date>
    </item>
    <item>
      <title>Re: Diff  Sync &amp; Async database update</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/diff-sync-async-database-update/m-p/2326723#M511403</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;A 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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;S 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&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;one simple example : You are creating sales order from file and also you want to update header text of sales order.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;when you want to update sales order header text,you need to use save_text function module ,here you need to pass sales order number.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;when you use call transaction update 'A', data will update transaction level and it goes to the next record,here it will not wait for database .&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;when you use call transaction update 'S',data will update transaction level and it will update database then it goes next record.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;if you want to update header text,then you need to use sync update&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;database commit - &lt;/P&gt;&lt;P&gt;comitt work - it will update data in database sucessfully&lt;/P&gt;&lt;P&gt;roll back - it will not update in database.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;&lt;P&gt;Seshu&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 02 Jun 2007 18:58:58 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/diff-sync-async-database-update/m-p/2326723#M511403</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-06-02T18:58:58Z</dc:date>
    </item>
    <item>
      <title>Re: Diff  Sync &amp; Async database update</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/diff-sync-async-database-update/m-p/2326724#M511404</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Imran,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Asynchronous Update &amp;#150; The program does not wait for the work process to finish the update. Commit Work.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Synchronous Update &amp;#150; The program wait for the work process to finish the update. Commit Work and Wait.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;DataBase Commit:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;An ordinary commit work will initiate the process to update the databases in a separate task and will press on in your abap.&lt;/P&gt;&lt;P&gt;COMMIT WORK: ( Asynchronous)&lt;/P&gt;&lt;P&gt;Your program does not wait for any acknowledgement. it just start executing the next statment after COMMIT WORK.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Reward if useful.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks&lt;/P&gt;&lt;P&gt;Aneesh.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 02 Jun 2007 19:05:41 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/diff-sync-async-database-update/m-p/2326724#M511404</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-06-02T19:05:41Z</dc:date>
    </item>
    <item>
      <title>Re: Diff  Sync &amp; Async database update</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/diff-sync-async-database-update/m-p/2326725#M511405</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;synchronous Update - It will update transaction level and it goes database level.&lt;/P&gt;&lt;P&gt;then it goes next record.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Asynchronous Update : it will update transaction level and lt goes next record.&lt;/P&gt;&lt;P&gt;later it updates database level.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Synchronous update is slow processing&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Asynchronous update is speed processing.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt; will tell you ,when you update the data at transaction level and it should update the data with respect to corresponding tables .. when you use asyn or syn ,all are sme but only thing is Syn update is it update the record transaction level and it goes db level and it will go next record.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;where as Asyn update ,it updates transaction level and it goes next record.but it updates DB Level later. &lt;/P&gt;&lt;P&gt;Database Commit:&lt;/P&gt;&lt;P&gt;Executes a database commit and thus closes a logical processing unit or Logical Unit of Work ( LUW ) (see also Transaction processing ). This means that &lt;/P&gt;&lt;P&gt;all database changes are made irrevocable and cannot be reversed with ROLLBACK WORK and &lt;/P&gt;&lt;P&gt;all database locks are released.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 04 Jun 2007 04:04:15 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/diff-sync-async-database-update/m-p/2326725#M511405</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-06-04T04:04:15Z</dc:date>
    </item>
    <item>
      <title>Re: Diff  Sync &amp; Async database update</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/diff-sync-async-database-update/m-p/2326726#M511406</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;HI,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;A href="http://fuller.mit.edu/tech/sync_asynchronous.html" target="test_blank"&gt;http://fuller.mit.edu/tech/sync_asynchronous.html&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The UPDATE addition determines the processing mode for batch input processing. You can specify a character-type object for upd. Its possible content and its effect are displayed in the following table. Without use of one of the additions UPDATE or OPTIONS FROM, the effect is the same as if upd had the content "A". &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Asynchronous update. Updates of called programs are executed in the same way as if in the COMMIT WORK statement the AND WAIT addition was not specified. &lt;/P&gt;&lt;P&gt;Synchronous processing. Updates of the called programs are executed in the same way as if in the COMMIT WORK statement the AND WAIT addition had been specified. &lt;/P&gt;&lt;P&gt;Local update. Updates of the called program are executed in such a way as if the SET UPDATE TASK LOCAL statement had been executed in it. &lt;/P&gt;&lt;P&gt;Other As for "A". &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Synchronous Update &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;In synchronous update, you do not submit an update request using CALL FUNCTION... IN UPDATE TASK. Instead, you use the ABAP statement COMMIT WORK AND WAIT. When the update is finished, control passes back to the program. Synchronous update works in the same way as bundling update requests in a subroutine (PERFORM ON COMMIT). This kind of update is useful when you want to use both asynchronous and synchronous processing without having to program the bundles in two separate ways. The following diagram illustrates the synchronous update process:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Use this type of update whenever the changed data is required immediately. For example, you may want to link SAP LUWs together where one LUW depends on the results of the previous one.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Asynchronous Update &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;A typical R/3 installation contains dialog work processes and at least one update work process. The update work processes are responsible for updating the database. When an ABAP program reaches a COMMIT WORK statement, any function modules from CALL FUNCTION... IN UPDATE TASK statements are released for processing in an update work process. The dialog process does not wait for the update to finish. This kind of update is called asynchronous update.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The following diagram shows a typical asynchronous update:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;For example, suppose a user wants to change an entry in a database table, or add a new one. He or she enters the necessary data, and then starts the update process by choosing Save. This starts the following procedure in the ABAP program:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Firstly, the program locks the database entry against other users, using the enqueue work process (or the message server in the case of a distributed system). This generates an entry in the lock table. The user is informed whether the update was successful, or whether the lock could not be set because of other users. &lt;/P&gt;&lt;P&gt;If the lock is set, the program reads the entry that is to be changed and modifies it. If the user has created a new entry, the program checks whether a record with the same key values already exists. &lt;/P&gt;&lt;P&gt;In the current dialog work process, the program calls a function module using CALL FUNCTION... IN UPDATE TASK, and this writes the change details as an entry in table VBLOG. &lt;/P&gt;&lt;P&gt;When the program is finished (maybe after further dialog steps), a COMMIT WORK statement starts the final part of the SAP LUW. The work process that is processing the current dialog step starts an update work process. &lt;/P&gt;&lt;P&gt;Based on the information passed to it from the dialog work process, the update work process reads the log entries belonging to the SAP LUW from table VBLOG. &lt;/P&gt;&lt;P&gt;The update work process passes this data to the database for updating, and analyzes the return message from the database. If the update was successful, the update work process triggers a database commit after the last database change and deletes the log entries from table VBLOG. If an error occurred, the update work process triggers a database rollback, leaves the log entries in table VBLOG, flags them as containing errors, and sends a SAPoffice message to the user, who should then inform the system administrator. &lt;/P&gt;&lt;P&gt;The corresponding entries in the lock table are reset by the update work process. &lt;/P&gt;&lt;P&gt;Asynchronous update is useful when response time from the transaction is critical, and the database updates themselves are so complex that they justify the extra system load of logging them in VBLOG. If you are running a transaction in a background work process, asynchronous update offers no advantages.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;check these thread..&lt;/P&gt;&lt;P&gt;&lt;A class="jive_macro jive_macro_message" href="https://community.sap.com/" __jive_macro_name="message" modifiedtitle="true" __default_attr="727442"&gt;&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;A class="jive_macro jive_macro_message" href="https://community.sap.com/" __jive_macro_name="message" modifiedtitle="true" __default_attr="1872225"&gt;&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;Priyanka.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 04 Jun 2007 04:07:16 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/diff-sync-async-database-update/m-p/2326726#M511406</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-06-04T04:07:16Z</dc:date>
    </item>
    <item>
      <title>Re: Diff  Sync &amp; Async database update</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/diff-sync-async-database-update/m-p/2326727#M511407</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;hi,&lt;/P&gt;&lt;P&gt;    Message: A 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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;S 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. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;L Local updating. If you update data locally, the update of the database will not be processed in a separate process, but in the process of the calling program. (See the ABAP keyword documentation on SET UPDATE TASK LOCAL for more information.)&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 04 Jun 2007 07:22:41 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/diff-sync-async-database-update/m-p/2326727#M511407</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-06-04T07:22:41Z</dc:date>
    </item>
  </channel>
</rss>

