Question: Why are there data records for modules and data in the update tables, but no header records? Is data lost as a result?
Why are there data records for modules and data in the update tables, but no header records? Is data lost as a result?
No! The update system is designed so that update modules and the data they contain are created during a transaction, but the update header is not generated until a "commit work".
This means that no update records are left by terminated transactions (transaction switch, terminating SAPGUI).
Nevertheless, you should delete "dead" update modules regularly. As reorganization during current operation also deletes update modules that have just been created, reorganization is prevented either when an application server is started or by a background job and a syslog message is issued.
 Question: What is a collective run?
Unlike V1 and V2 updates, V3 updates (or collective runs) are not started directly. The update is performed by a background job (report RSM13005). In this case, the update requests are not updated separately, but rather all modules of the same type are updated in a single database transaction. As the database can operate with far fewer database transactions, system performance is dramatically improved. Background jobs should be started in Customizing of the relevant applications that use the V3 update.
 Question: What is the difference between V1, V2 and V3 (collective run) modules?
The type of update module for a function module is defined by the developer and then saved as a property of the function module. The properties are defined as follows:
V1: The update should be performed soon. The update record is protected by R/3 locks. The update is critical for the operational consistency of the system.
V2: The update does not have to be performed soon. The update is not protected by locks. The update modules do not contain "vital" data.
V3: As V2, but, you use report RSM13005 to start the updates.
Note that the V3 update offers an advantage with regard to speed when considering its disadvantages. Report RSM13005 also eliminates some of the disadvantages of the V3 update.
 Question: What is the purpose of the update concept?
The transaction concept of the R/3 system and the update are basically different. A database transaction is terminated after every dialog step; the R/3 data can only be copied when it is saved to the database. Therefore, the R/3 system simulates the database access and saves all data in the update tables. All of the database accesses in a database transaction are not written to the database until a transaction is terminated.
 Question: What should I do with terminated update records?
You must first determine whether an update record can be updated again. This is possible under the following conditions:
- All update modules of the update record can be updated again.
- The update record was not created using batch input or from another system (for example, using ALE).
Remember that when an update termination occurs, the user involved receives an express mail and then usually all users try to save their data in the system. Generally they try to save their data again or solve the problems that led to the termination. Duplicate data records are created if the data is also updated again by the update control (SM13). For this reason, if update terminations occur, the system administrator must always determine with the affected users what has already been done and what is still to be done. All other actions are potentially prone to duplicate records and can lead to system inconsistencies. Repeating a transaction and deleting the affected update record is always preferable to updating records again.
If you cannot repeat a transaction and the update record can be updated again, you can repeat the update using the "Update records" -> "Repeat update" menu option in transaction SM13.
You can restart update records that remain with the "init" or "V1" status by choosing "Update records -> Update ->...". You must ensure in advance that these records are not already in the dispatcher queue for updating.
 Question: Can you start report RSM13005 in parallel?
Report RSM13005 is called with the name of the collective run function module that you want to activate. A relevant R/3 lock is set for this name, which you can also see in SM12. This means the report CANNOT be started for the same collective run function module, but for VARIOUS collective run function modules.
- Latest ABAP interview questions-answers part-1
- Latest ABAP interview questions-answers part-2
- BDC Program Interview Question and Answer
- ABAP DATA TYPES and DATA OBJECTS
- SAP ABAP Scripts Question and Answers Part 4
- SAP ABAP Report Programming Questions 1
- SAP ABAP Scripts Question and Answers
- What is ABAP/4 Data Dictionary?
- SAP ABAP Scripts Question and Answers Part 5 (contd.)
- Interview Question of SAP ABAP for Fresher
- ABAP and Java Dictionary data type system in comparison...?
- F-44 Entered Data but Shows ABAP Run Time Error
- SAP BASIS INTERVIEW QUESTIONS ON DATABASE
- Interview Questions on RMAN, Flashback and DG.
- Abap Program for retrieving the Archive Data
- SAP HA ABAP Add on Installation
- ABAP query on BP_JOB_SELECT
- Important Basis Interview Question And Answer.
- Dot Net and ABAP
- ABAP Performance Tuning
- ABAP Cookbook
- Discover ABAP
- Object-Oriented Programming with ABAP Objects
- SAP BC - ABAP Programming
- BC - ABAP Programming
- ABAP Programming & Coding Standards
- Programming Database Updates in ABAP
- SAP NetWeaver AS ABAP - System Administration
- TABC41 ABAP Development Workbench Basics Certification Material for SAP ABAP
SAP ABAP | Hyderabad |
Exp :1 - 3 years | City : Hyderabad
ABAP HANA Consultant Job | 5 - 8 yrs | Bengaluru | SAP India
Exp :3 - 5 years | City : Bangalore
SAP ABAP HR Certified Consultant
Exp :2 - 15 years | City : Delhi
SAP ISU EDM Consultant
Exp :5 - 15 years | City : Bangalore
Exp :2 - 7 years | City : Delhi
Urgent requirement |SAP SD Techno functional
Exp :5 - 11 years | City : Bangalore
SAP Hana Cloud Integeration | 6 - 9 Years | Pune | Atos
Exp :6 - 9 years | City : Pune
SAP ABAP Webdynpro | 4 - 9 Years | Pune, Bangalore | Atos
Exp :4 - 9 years | City : Bangalore
SAP SD | 4 - 8 Years | Ahmedabad | Gi Group
Exp :4 - 8 years | City : Ahmedabad
SAP ABAP Technical Consultant | 3 - 6 yrs | Bangalore | Inct
Exp :3 - 6 years | City : Bangalore