Database Update

Information

• This topic describes the update procedure of the PLANTA database.
• This topic only addresses issues which apply to the database update alone.

Requirements and Recommendations

Caution

• The update of PLANTA database requires know how in the area of PLANTA customizer since some update steps refer back to PLANTA customizer functions and modules. Ideally, the update should be carried out by an IT-administrator (parametrization in PLANTA Installer) and a customizer (check of the update results, check of the migration packets, conflict management, etc.). The description of the customizing-specific topics like migration procedure, conflict management, etc., can be found in the PLANTA customizer documentation.
• Please read the system requirements before you begin with the PLANTA database update.

We recommend that

• before a database update
  • you carry out a consistency check (at least a releation check) check the source system to verify the validity of the data.
  • create a backup of the source system (database and server).
• In the case of a database update, PLANTA recommends that you do this in a test system first, before updating the productive system.
• In database update, PLANTA recommends that you update the server to the most recent version available as well. For the description of server update, please click here.
• If you have any questions with regard to the basic conditions of the update procedure, please contact your PLANTA consultant.

Procedure

The update including the migration process is carried out via PLANTA Installer.

Procedure

• Step 1: Download the database folder of the required release from the PLANTA Transfer Server.
• Step 2: Carry out an update of the database via PLANTA Installers. For this purpose, carry out the steps listed in the technical procedure section (depending on the status of the source system, the respective chapters are to be taken into consideration).
• Step 3: Check the status of the migration packets (i.e. whether they have run correctly) in the individual modules of the Migration packets panel. If a packet has not run correctly, you must check the log file of the migration packet and possibly take appropriate measures. For further information, please go to the Overview of All Previous Runs topic.
• Step 4: Check and possibly execute the standard ICOU
• Step 5: Use the new conflict management procedure to check and resolve the conflicts which arise as a result of the DB update.
  • Here, conflicts are changes to standard objects in which you must check whether the individual adjustment is to be retained or to be replaced by the new PLANTA standard.

Technical Procedure

Information

• Below, you will find a description of the technical procedure for update of the PLANTA database.

From a technical point of view, the DB update consists of the following steps:

1. Execute the open migration packets in the folder or in the Customizing category
   • As a result, the migration packets from the different database releases will be run successively. These migration packets serve to adjust the schema to the respective database release, e.g. to create new columns on the database. The corresponding system and module customizings are updated in step 4.
   • For which database release a migration packet is relevant is defined in the migration packet itself.
2. Execute the migration packets in Before DB Import, this includes, a.o. the following migration packets that are run during every database update:
   • CorrectOwnerLicense: Sets the owner license for all records in Q1B and Q2B with empty owner license. Whether the record receives the standard or the customer license is determined by the automatic number as in most data tables. For data tables in which this is not possible (since the license is not part of the automatic number or there is no auto number), own rules have been defined.
   • DeleteStandardConstraintsQ1BandQ2B: Deletes all standard constraints in Q1B and Q2B, except primary and unique constraints.
   • SetOwnerLicenseForZZZRecords: Changes the owner license in the data tables of Q1B and Q2B from ZZZ to 011.
3. DB import (=Replacing the customizing in PLANTA project, see also Database Export/Import). In the course of this,
   • existing constraints and triggers are deactivated,
   • the data with PLANTA license (000 and 011) in the data tables of Q1/Q2 (and parts of Q3 (e.g. module variants), as well as the process model tables in Q5) are deleted table wise
   • the data in the same tables is newly imported.
   • the previously deactivated constraints/triggers are reactivated.
4. Execute the migration packets in After DB Import, this includes, a.o., the following migration packets that are run during every database update:
   • DeleteStandardConstraintsAfterDBImport: Deletes all constraints that lead to standard DIs (in all schemas, including primary and unique constraints)
   • DeleteStandardIndices: Deletes all indeces on UUID DIs as well as old indices.
   • A_CreateConstraints: Creates all constraints from the schema generation. As a result, the constraints are created first and in a second step they are validated. Problems that occur during validation, e.g. due to incorrect data, are written in the log file. They must be checked and corrected manually. Afterwards, the constraints must be validated via the EnableConstraints migration packet.
   • AddSchemaExtensions: Adds indices and constraints that do not result directly from the system customizing.
   • UnloadAndReplan: Carries out a replanning of all active projects.
   • In addition, the following checks of the consistency check are carried out (they are located in the Help Packets module)
     • HyperlinkCheckPacket: Executes the Hyperlink Check and Correction
     • ItextCheckPacket: Executes the I-Text Check and Correction
     • PlaceholderCheckPacket: Executes the Dash Record Check and Correction
5. Adjust the imported data
   • Here, the licenses of the newly entered data are adjusted to the customer license in the first place.

Note

• The replacement of the customizing during DB import in step 3 "DB import" is done analogously to the customizing deployment of customer systems with the difference being that in CU deployment all records in Q1B and Q2B are deleted and reimported while in DB import only those with 011 and 000 standard owner licenses are deleted and reimported.
  • The requirements of the customizing deployment, like the program status and the same database schema, are created by the update procedure itself during database update (e.g. with the help of migration packets).