The frequency and usefulness of reloading depend on the archiving method.
In standard archiving, reloading should be the absolute exception. A simple display requirement can always be fulfilled without reloading via the Archive Cockpit. Possible cases that require reloading specifications from the standard archive are as follows:
Data must be reloaded shortly after archiving because the selection criteria of the archiving program were incorrect. This is a valid case and should work without any problems since it is very unlikely that structures and object dependencies in the system have changed since the incorrect run.
Data is to be reloaded after a long period of time because you want to use it again. This can be associated with considerable risks since the probability is very high that dependencies or even structures within the system have changed in the meantime so that the reloaded data becomes inconsistent. If a reload should nevertheless be necessary, it must be ensured that all dependencies still exist or were also reloaded previously.
Version archives, on the other hand, are designed for this very requirement, to store a backup of one or many specifications that can be restored at any time. This means that the same risks exist here, but by sticking with a periodic backup approach, it is more likely to avoid bad situations caused by archiving the same set of specifications for each run. This means that the last version to be considered for reloading is not too far away in terms of age.
Execute (F8)
Since reloading is considered an exceptional requirement, there is no action for this task in the usual list of functions after entering an archive object in SARA. Instead, one could go via the menu bar.
However, since reloading QPPD specifications is very complex, it works somewhat differently than the standard ADK procedure for reloading data. Therefore, SARA should not be used for this requirement.
Start transaction /SCT/QP_ARES, and the selection screen for reloading data appears.
The first options allow you to restrict specifications for reloading using ranges for some of the most important attributes. To note: The ranges defined here can only be applied to specifications archived under the ARCID specified directly below.
The archive ID must be entered to define the ARCID containing the specifications to be reloaded. Only one ARCID can be specified at a time. This means that if multiple archives are to be reloaded, the transaction must be executed multiple times.
If test mode is activated, all actions are executed as usual, but no changes are transferred to the database. Logs and statistics are written nevertheless.