<?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: what do you mean by commit command in Application Development and Automation Discussions</title>
    <link>https://community.sap.com/t5/application-development-and-automation-discussions/what-do-you-mean-by-commit-command/m-p/3431092#M824135</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Praveen,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;read the below  doc. very very useful one.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Error Handling for Bundled Updates &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Runtime errors can occur during execution of bundled updates. How are they handled? In general, COMMIT WORK processing occurs in the following order:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;All dialog-task FORM routines logged with PERFORM ON COMMIT are executed. &lt;/P&gt;&lt;P&gt;All high-priority (V1) update-task function modules are executed. &lt;/P&gt;&lt;P&gt;The end of V1-update processing marks the end of the . If you used COMMIT WORK AND WAIT to trigger commit processing, control returns to the dialog-task program. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;All low-priority (V2) update-task function modules are triggered.&lt;/P&gt;&lt;P&gt;All background-task function modules are triggered.&lt;/P&gt;&lt;P&gt;Runtime errors can occur either in the system itself, or because your program issues an termination message (MESSAGE type &amp;#145;A&amp;#146;). Also, the ROLLBACK WORK statement automatically signals a runtime error. The system handles errors according to where they occur:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;in a FORM routine (called with PERFORM ON COMMIT)&lt;/P&gt;&lt;P&gt;Updates already executed for the current update transaction are rolled back. &lt;/P&gt;&lt;P&gt;No other FORM routines will be started. &lt;/P&gt;&lt;P&gt;No further update-task or background-task functions will be started. &lt;/P&gt;&lt;P&gt;An error message appears on the screen.&lt;/P&gt;&lt;P&gt;in a V1 update-task function module (requested IN UPDATE TASK)&lt;/P&gt;&lt;P&gt;Updates already executed for V1 functions are rolled back. &lt;/P&gt;&lt;P&gt;All further update-task requests (V1 or V2) are thrown away. &lt;/P&gt;&lt;P&gt;All background-task requests are thrown away. &lt;/P&gt;&lt;P&gt;Updates already executed for FORM routines called with PERFORM ON COMMIT are not rolled back. &lt;/P&gt;&lt;P&gt;An error message appears on the screen, if your system is set up to send them&lt;/P&gt;&lt;P&gt;in a V2 update-task function module (requested IN UPDATE TASK)&lt;/P&gt;&lt;P&gt;Updates already executed for the current V2 function are rolled back. &lt;/P&gt;&lt;P&gt;All update-task requests (V2) still to be executed are discarded. &lt;/P&gt;&lt;P&gt;All background-task requests still to be executed are carried out. &lt;/P&gt;&lt;P&gt;No updates for previously executed V1 functions are rolled back. &lt;/P&gt;&lt;P&gt;No updates previously executed for FORM routines (called with ON COMMIT) are rolled back. &lt;/P&gt;&lt;P&gt;An error message appears on the screen, if your system is set up to send them&lt;/P&gt;&lt;P&gt;in a background-task function module (requested IN BACKGROUND TASK DESTINATION)&lt;/P&gt;&lt;P&gt;Background-task updates already executed for the current DESTINATION are not rolled back. &lt;/P&gt;&lt;P&gt;All further background-task requests for the same DESTINATION are thrown away. &lt;/P&gt;&lt;P&gt;Other previously executed updates are rolled back. &lt;/P&gt;&lt;P&gt;No error message appears on the screen.&lt;/P&gt;&lt;P&gt;If your program detects that an error in remote processing has occurred, it can decide whether to resubmit the requests at a later time.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;For further information about RFC processing, refer to the Remote Communications documentation.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Mon, 25 Feb 2008 03:14:31 GMT</pubDate>
    <dc:creator>Former Member</dc:creator>
    <dc:date>2008-02-25T03:14:31Z</dc:date>
    <item>
      <title>what do you mean by commit command</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/what-do-you-mean-by-commit-command/m-p/3431091#M824134</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;hi gurus,&lt;/P&gt;&lt;P&gt; &lt;/P&gt;&lt;P&gt;  what do you mean by commit command, and how we can use in subroutines...&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;regards,&lt;/P&gt;&lt;P&gt;praveen&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sun, 24 Feb 2008 12:49:00 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/what-do-you-mean-by-commit-command/m-p/3431091#M824134</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2008-02-24T12:49:00Z</dc:date>
    </item>
    <item>
      <title>Re: what do you mean by commit command</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/what-do-you-mean-by-commit-command/m-p/3431092#M824135</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Praveen,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;read the below  doc. very very useful one.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Error Handling for Bundled Updates &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Runtime errors can occur during execution of bundled updates. How are they handled? In general, COMMIT WORK processing occurs in the following order:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;All dialog-task FORM routines logged with PERFORM ON COMMIT are executed. &lt;/P&gt;&lt;P&gt;All high-priority (V1) update-task function modules are executed. &lt;/P&gt;&lt;P&gt;The end of V1-update processing marks the end of the . If you used COMMIT WORK AND WAIT to trigger commit processing, control returns to the dialog-task program. &lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;All low-priority (V2) update-task function modules are triggered.&lt;/P&gt;&lt;P&gt;All background-task function modules are triggered.&lt;/P&gt;&lt;P&gt;Runtime errors can occur either in the system itself, or because your program issues an termination message (MESSAGE type &amp;#145;A&amp;#146;). Also, the ROLLBACK WORK statement automatically signals a runtime error. The system handles errors according to where they occur:&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;in a FORM routine (called with PERFORM ON COMMIT)&lt;/P&gt;&lt;P&gt;Updates already executed for the current update transaction are rolled back. &lt;/P&gt;&lt;P&gt;No other FORM routines will be started. &lt;/P&gt;&lt;P&gt;No further update-task or background-task functions will be started. &lt;/P&gt;&lt;P&gt;An error message appears on the screen.&lt;/P&gt;&lt;P&gt;in a V1 update-task function module (requested IN UPDATE TASK)&lt;/P&gt;&lt;P&gt;Updates already executed for V1 functions are rolled back. &lt;/P&gt;&lt;P&gt;All further update-task requests (V1 or V2) are thrown away. &lt;/P&gt;&lt;P&gt;All background-task requests are thrown away. &lt;/P&gt;&lt;P&gt;Updates already executed for FORM routines called with PERFORM ON COMMIT are not rolled back. &lt;/P&gt;&lt;P&gt;An error message appears on the screen, if your system is set up to send them&lt;/P&gt;&lt;P&gt;in a V2 update-task function module (requested IN UPDATE TASK)&lt;/P&gt;&lt;P&gt;Updates already executed for the current V2 function are rolled back. &lt;/P&gt;&lt;P&gt;All update-task requests (V2) still to be executed are discarded. &lt;/P&gt;&lt;P&gt;All background-task requests still to be executed are carried out. &lt;/P&gt;&lt;P&gt;No updates for previously executed V1 functions are rolled back. &lt;/P&gt;&lt;P&gt;No updates previously executed for FORM routines (called with ON COMMIT) are rolled back. &lt;/P&gt;&lt;P&gt;An error message appears on the screen, if your system is set up to send them&lt;/P&gt;&lt;P&gt;in a background-task function module (requested IN BACKGROUND TASK DESTINATION)&lt;/P&gt;&lt;P&gt;Background-task updates already executed for the current DESTINATION are not rolled back. &lt;/P&gt;&lt;P&gt;All further background-task requests for the same DESTINATION are thrown away. &lt;/P&gt;&lt;P&gt;Other previously executed updates are rolled back. &lt;/P&gt;&lt;P&gt;No error message appears on the screen.&lt;/P&gt;&lt;P&gt;If your program detects that an error in remote processing has occurred, it can decide whether to resubmit the requests at a later time.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;For further information about RFC processing, refer to the Remote Communications documentation.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 25 Feb 2008 03:14:31 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/what-do-you-mean-by-commit-command/m-p/3431092#M824135</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2008-02-25T03:14:31Z</dc:date>
    </item>
  </channel>
</rss>

