Question: 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.