<?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: synchronous processing in call transaction in Application Development and Automation Discussions</title>
    <link>https://community.sap.com/t5/application-development-and-automation-discussions/synchronous-processing-in-call-transaction/m-p/2368274#M524531</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;hI&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;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;&amp;lt;b&amp;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;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.&amp;lt;/b&amp;gt; &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;Reward points if useful&lt;/P&gt;&lt;P&gt;Regards&lt;/P&gt;&lt;P&gt;Anji&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Fri, 01 Jun 2007 07:19:08 GMT</pubDate>
    <dc:creator>Former Member</dc:creator>
    <dc:date>2007-06-01T07:19:08Z</dc:date>
    <item>
      <title>synchronous processing in call transaction</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/synchronous-processing-in-call-transaction/m-p/2368273#M524530</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi experts,&lt;/P&gt;&lt;P&gt;               1.what is the synchronous processing in call transaction method?&lt;/P&gt;&lt;P&gt;                  I want exactly how data transfers from flat file to internal table and internal table to application,application to database during synchronous proceessing in call transaction method?&lt;/P&gt;&lt;P&gt;              &lt;/P&gt;&lt;P&gt;Pls help me in this regard&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;thanks inadvance&lt;/P&gt;&lt;P&gt;surya.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 01 Jun 2007 07:13:29 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/synchronous-processing-in-call-transaction/m-p/2368273#M524530</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-06-01T07:13:29Z</dc:date>
    </item>
    <item>
      <title>Re: synchronous processing in call transaction</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/synchronous-processing-in-call-transaction/m-p/2368274#M524531</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;hI&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;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;&amp;lt;b&amp;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;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.&amp;lt;/b&amp;gt; &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;Reward points if useful&lt;/P&gt;&lt;P&gt;Regards&lt;/P&gt;&lt;P&gt;Anji&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 01 Jun 2007 07:19:08 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/synchronous-processing-in-call-transaction/m-p/2368274#M524531</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-06-01T07:19:08Z</dc:date>
    </item>
    <item>
      <title>Re: synchronous processing in call transaction</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/synchronous-processing-in-call-transaction/m-p/2368275#M524532</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;if you are using synchronous database update, no transaction is started until the previous transaction has been written to database.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;ie. while uploading ten records and if the system finds any error in the second record it wont allow to save the third  record until the second record has been get save.&lt;/P&gt;&lt;P&gt;but if you use asynchronous database update the system skip the second record and the next successive non error record get saved. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks,&lt;/P&gt;&lt;P&gt;Anitha&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 01 Jun 2007 07:20:55 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/synchronous-processing-in-call-transaction/m-p/2368275#M524532</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-06-01T07:20:55Z</dc:date>
    </item>
    <item>
      <title>Re: synchronous processing in call transaction</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/synchronous-processing-in-call-transaction/m-p/2368276#M524533</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;&lt;/P&gt;&lt;P&gt;Regards&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 01 Jun 2007 07:43:31 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/synchronous-processing-in-call-transaction/m-p/2368276#M524533</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-06-01T07:43:31Z</dc:date>
    </item>
    <item>
      <title>Re: synchronous processing in call transaction</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/synchronous-processing-in-call-transaction/m-p/2368277#M524534</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;PRE&gt;&lt;CODE&gt;Call transaction	&amp;lt;tcode&amp;gt; using &amp;lt;BDCTAB&amp;gt;
	Mode &amp;lt;A/N/E&amp;gt;
	Update &amp;lt;S/A&amp;gt;
	Messages into &amp;lt;MSGTAB&amp;gt;.&lt;/CODE&gt;&lt;/PRE&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Parameter &amp;#150; 1	is transaction code.&lt;/P&gt;&lt;P&gt;Parameter &amp;#150; 2	is name of BDCTAB table.&lt;/P&gt;&lt;P&gt;Parameter &amp;#150; 3	here you are specifying mode in which you execute transaction&lt;/P&gt;&lt;P&gt;		A is all screen mode.  All the screen of transaction are displayed.&lt;/P&gt;&lt;P&gt;		N is no screen mode. No screen is displayed when you execute the transaction.&lt;/P&gt;&lt;P&gt;	E is error screen. Only those screens are displayed wherein you have error record.&lt;/P&gt;&lt;P&gt;Parameter &amp;#150; 4	here you are specifying update type by which database table is updated.&lt;/P&gt;&lt;P&gt;	&amp;lt;b&amp;gt;S is for Synchronous update in which if you change data of one table then all the related Tables gets updated. And sy-subrc is returned i.e., sy-subrc is returned for once and all.&amp;lt;/b&amp;gt;&lt;/P&gt;&lt;P&gt;	A is for Asynchronous update. When you change data of one table, the sy-subrc is returned. And then updating of other affected tables takes place.  So if system fails to update other tables, still sy-subrc returned is 0 (i.e., when first table gets updated).&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Parameter &amp;#150; 5	when you update database table, operation is either successful or unsuccessful or operation is successful with some warning. These messages are stored in internal table, which you specify along with MESSAGE statement. This internal table should be declared like BDCMSGCOLL, a structure available in ABAP/4. It contains the following fields:&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 01 Jun 2007 07:46:56 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/synchronous-processing-in-call-transaction/m-p/2368277#M524534</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-06-01T07:46:56Z</dc:date>
    </item>
    <item>
      <title>Re: synchronous processing in call transaction</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/synchronous-processing-in-call-transaction/m-p/2368278#M524535</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;hi,&lt;/P&gt;&lt;P&gt;   i want how synchronous processing is happening?&lt;/P&gt;&lt;P&gt;   that means how the data is transfering from internal table to application?&lt;/P&gt;&lt;P&gt;   if one record is read from internal table and after validated control goes to database or control returns to second record?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;pls give me relavent information for the above questions?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 01 Jun 2007 14:34:35 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/synchronous-processing-in-call-transaction/m-p/2368278#M524535</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2007-06-01T14:34:35Z</dc:date>
    </item>
  </channel>
</rss>

