The documentation from version 39.5.17 of PLANTA project can be found in the new PLANTA Online Help.
TWiki> CurrentEN Web>InstallationAndUpdate>UpdatePLANTAProject>DatabaseUpdate

Database Update New from DB 39.5.7

Information
  • This topic describes the update of the PLANTA database
    • from version 39.4.4.0 (Earth) to a 39.5 version (Venus) as well as
    • from a 39.5 version (Venus) to a higher 39.5. version (Venus)
  • This topic only addresses issues which apply to the database update alone.
    • In database update, PLANTA recommends to update the server to the most recent version available as well. For a description of the server update, please refer to either UpdateServer394To395 or UpdateServer395, depending on your root version.
  • For a complete overview of different combinations (according to your system version and the version to which you want to update), please refer to this description.

Requirements and Recommendations

Requirements

  • All data tables with foreign kesy constraints on PLANTA data tables must exist in PLANTA project as data tables, since otherwise problems may occur, a.o., in database update.
  • Before the database update, all foreign key constraints to PLANTA data tables must be deleted manually and then be created anew after the update.

Before updating, we recommend that you

  • carry out a consistency check on the source systen (at least the relation check).
  • create a back-up of the source system (database and server).

Procedure

The update including the migration process is carried out with the PLANTA installer.

From DB 39.5.15

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 by means of the PLANTA installer. 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, refer to the Overview of All Previous Runs topic.
  • Step 4: Check and possibly execute the standard ICOU
  • Step 5: NEW 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.
    • The procedure in the application of the conflict management procedure varies depending on the version from which you update. In the following table, both possible options are listed:
Update from DB < DB 39.5.14 to DB 39.5.15 or later 1 Import reference system in the Import Reference module. (First insert the schema via Reference path field and subsequently import the data-zip file. The file extension (.sql or .zip) determines the file type.)
2 Click on the Find adjustments button. As a result, the conflicts are initiated.
3 In the Conflicts module, the solutions for conflicts can now be configured and executed in their respective modules.
Update from DB 39.5.14 to DB 39.5.15 or later In the Conflicts module, the solutions for conflicts can now be configured and run in their respective modules.

From DB 39.5.14

Procedure
  • Download the database folder from the PLANTA Transfer Server.
  • Carry out an update of the database using the PLANTA installer. 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).
  • Check migration packets
    • If packets fail, the log files must be checked and the customizings may need to be corrected.
      • E.g.: If the A_CreateConstraints migration packet fails, the incorrect data which is displayed in the log file of the migration packet is checked and either corrected or deleted. Afterwards, the EnableConstraints migration packet must be carried out, with the help of which the not yet validated constraints are validated. Must only be run after all data which was reported in A_CreateConstraints has been corrected.
  • Check and possibly execute the standard ICOU
  • This step depends on the release from which you update to DB 39.5.14.
    • If you update from an Earth or Venus on Earth release (DB 39.4.4.0),
    • If you update from a Venus release (DB 39.5.x),
      • NEW a new conflict management procedure can be used to check for and resolve conflicts which occur in 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 PLANTA Standard.
        • Reference system in the Import Reference module
          • First insert the schema via Reference path field and subsequently import the data-zip file. The file extension (.sql or .zip) determines the file type
        • Click on the Find adjustment button in the same module. As a result, the conflicts are initiated.
        • In the Conflicts module, the conflicts can now be configured and executed in their respective modules. Further information on the conflict management during DB update

Up to DB 39.5.14

Procedure
  • Download the database folder from the PLANTA Transfer Server.
  • Carry out an update of the database using the PLANTA installer. 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).
  • Check migration packets
    • If packets fail, the log files must be checked and the customizings may need to be corrected.
      • E.g.: If the A_CreateConstraints migration packet fails, the incorrect data which is displayed in the log file of the migration packet is checked and either corrected or deleted. Afterwards, the EnableConstraints migration packet must be carried out, with the help of which the not yet validated constraints are validated. Must only be run after all data which was reported in A_CreateConstraints has been corrected.
  • Check and possibly execute the standard ICOU
  • Check and execute the standard ICOU

Technical Procedure

DB Update DB 39.5.x (Venus) to DB 39.5.y (Venus)

Information
  • Below, the technical procedure for the update of a PLANTA database which is already on a 39.5 version (Venus) to a higher 39.5 version (Venus) is described.
  • In the PLANTA Installer, this update type is called venus when updating via console and Update from Release 39.5.x (with DB 39.5) when updating via GUI.

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 are 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)
  • 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).

DB Update DB 39.4.4.0 with S 39.5.x (Venus on Earth) to DB 39.5.x (Venus)

Information
  • The technical procedure for the update of this version is the same as for the update from DB 39.5.x (Venus) to DB 39.5.y (Venus) which is described above.
  • In the PLANTA Installer, this update type is named r95 when updating via console and Update from Release 39.5.x (with DB 39.4) when updating via GUI.

DB-Update 39.4.4.0 with S 39.4.4.0 (Earth) on DB 39.5.x (Venus)

Information
  • If you use Database 39.4.4.0 with Server 39.4.4.0 (i.e.: the entire system is an Earth version), you cannot update your database directly to a 39.5.x version (Venus).
  • Here, two individual updates must be carried out
    • 1: First, the server must be updated to a 39.5.x version, in the PLANTA Installer this update type is called r94 when updating via console and Update from Release 39.4.4.0 to Release 39.5.x (with DB 39.4) when updating via GUI.
      • For this purpose, see the description in the Update Server 39.4 to Server 39.5 topic.
      • We recommend that you create a back-up of this interim state of the DB update.
      • After this step has been carried out, your system will be on version DB 39.4.4.0 with server 39.5.x (Venus on Earth).
    • 2. Then the database can be updated to a 39.5.x version. In the PLANTA Installer,this update type is called voeToVenus when updating via console and Migrate from DB 39.4 to DB 39.5 (with release 39.5.x when updating via GUI.

         PLANTA project







 
  • Suche in Topic-Namen

  • Suche in Topic-Inhalten
This site is powered by the TWiki collaboration platform Powered by Perl