Cross-Release Packets MOD009CEP
Access
- Customizer → Migration → Migration Packets panel → Cross-Release Packets
Information
- This module contains release independent and cross release migration packets.
- The
RebuildTableIndicesVenusMSSQL
migration packet creates a new construction of the indexes under MSSQL in order to improve performance. It can be executed as often as required. - The
FillMigrationruleTable
migration packet serves to search for individually written packets in the file directory, save them in the database and load them in the module. - The
CreateFolderPacket
migration packet creates an import wrapper for all Python files and packets in order for them to be available for the PLANTA Server. Further information.
- The
Buttons and Links
- Via the Read packet from file system button, individually written packets can be searched in the file directory and be loaded in the module.
- Migration packets with Upon system start = will automatically be run after update via installer when the Run migration? parameter has been set accordingly.
- For migration packets that are not run automatically you also have the option to switch to the Overview of all Previous Runs module by clicking on the link on the packet name.
- There you can run the packet and see further information about it (e.g. logfile of the runs, etc.).
Legend
- signalizes that this migration packet has not yet been executed.
- means that the migration packet has run successfully.
- signalizes that this migration packet is still pending and waits for another migration packet to reach a certain status before it can be executed.
- Signalizes that this migration packet is not relevant for the current update type due to version dependencies.
- signalizes that the migration packet has failed. There may be several causes for a packet to fail:
- Many migration packages check whether the customizing on which the fix is based has changed before they are executed.
- If this is the case, the change to the package is not made and the package is deemed to have failed.
- In such a case, you have to check in the customizing whether and how the respective change can be made.
- If the change has been made or if the change is not necessary, the package can be manually set to completed by activating the Completed checkbox.
- This will move it from the Failed/pending packets area to the Completed Packets module.
- If this is the case, the change to the package is not made and the package is deemed to have failed.
- Many migration packages check whether the customizing on which the fix is based has changed before they are executed.
Many auxiliary packets check the customizing for problems.
- If they fail, this means that the customizer must act.
- The locations listed in the log file must be checked and adjusted if necessary.
- Once the cause of the failure has been eliminated, the migration packet can be executed again by clicking on the Execute packet button in the Overview of All Previous Runs module.