Maintenance Notice - PDF Generation
Dynamic PDF generation for web-based content is temporarily unavailable. This maintenance affects dynamic PDF files that are generated from either the HTML-based page or manual that you are viewing. Links that normally allow this functionality have been hidden, and will reappear as soon as the feature is restored.


Note: Access to static files, including PDF files that are not dynamically generated from our web-based content, is unaffected.

Jump to: navigation, search

Pulse Advisors Data Migration Paths

Typically, Advisors data migration from an originating version to a target version must include migrations to all of the target releases that exist between the originating and the target versions, although some exceptions apply. Follow the notes in the tables on this page (see Data Migration Paths) to be sure that you are migrating your Advisors data correctly. The information on this page is specific to migrations from release 8.5.101.09 to release 9.0.002.03. This guide also contains additional information about migrating databases to Advisors release 8.5.2.

See general migration procedures on the following pages:

In Oracle installations, the migration to each target version involves the migration of both the Advisors Genesys Adapter (AGA) metrics schema and the Advisors Platform schema of the same version. In other words, you cannot migrate the Platform schema through all versions that exist between the originating version and the target version but then migrate the AGA metrics schema from the originating version directly to the target version; the AGA metrics schema must be migrated incrementally as well.

In all cases on this page where it states that you must execute one specific script and you choose to run its SQL*Plus version, then you must execute the script from its original folder or its exact copy. This is because SQL*Plus versions of the scripts normally call other scrips that are expected to be in the same folder. The SQL*Plus version of the scripts contain "plus" in their names when directly executed.

In MSSQL installations, Genesys recommends that you migrate the Platform database to every version between the originating and the pre-target version. Then follow the migration instruction for the target version to bring the AGA, Platform, and metric graphing schema to the target version. For example, if the migration is done from version A to C with B as the intermediate version between A and C:

  1. Perform the Platform database migration from A to B.
  2. Next, perform the AGA metrics database migration from version A directly to version C (skipping over version B).
  3. Finally, migrate the Platform database from version B to C.

Depending on the MSSQL Server version and the database content, some migration scripts that are used to migrate from an originating to a pre-target version can issue Invalid column name errors. You can ignore such errors, while the migration to target versions should be error-free.

The metric graphing schema can be migrated directly from the originating version to the target version in either installation, Oracle or MSSQL.

In addition to the database content, Advisors components depend on some data held in the Configuration Server. You might also need to migrate or append the data in the Configuration Server as part of the migration process. To do this, you use the Migration Wizard. You must use the Migration Wizard in the following scenarios:

  1. If you decide to enable metrics that are not yet present in your Configuration Server.
  2. If you use metric filters or object segmentation filters and you migrate to version 9.0.000.06 or later.
  3. If you plan to use the default rollup configuration mode and your target version is 9.0.001.06 or later.

Data Migration Paths

Click a link to see the table of information specific to that migration path:

* Advisors release 8.5.201.26 is included in the following tables for those who installed this version (it was a restricted-access release). If you did not install release 8.5.201.26 in your environment, then you can omit migration path steps that include that release.


Originating version 8.5.101.09
Target version 8.5.101.17
Script to migrate to the target version from the original version advisors-platform-migrateSchema_8.5.101.09_8.5.101.17.sql
AGA schema dependencies

Before you apply the Platform migration script, migrate the AGA metrics schema to the target version by connecting as the AGA metrics schema owner and running any gc_metrics_<targetversion>_Objectsxxx.sql script for Oracle or gc_metrics_db_<target version>.sql script for MSSQL Server installations. There is no need to drop any AGA metrics objects before applying the script. Once the corresponding script is applied, in Oracle installations grant select privileges to the Platform schema owner as follows:

GRANT SELECT ON AGENT_SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON CALL_TYPE TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON CALL_TYPE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON CONTROLLER_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON INTERACTION_QUEUE TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON INTERACTION_QUEUE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON LOGICAL_INTERFACE_CONTROLLER TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON PERIPHERAL TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON PERIPHERAL_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON QUEUE_SET1_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON QUEUE_SET2_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SERVICE TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SERVICE_MEMBER TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SERVICE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SKILL_GROUP TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;

Proceed to the Platform schema migration.

Platform schema migration specifics

In Oracle installations, before the Platform migration script is applied, ask your DBA to verify that the Platform schema owner is granted the following privileges:

CREATE SESSION,CREATE TABLE,CREATE OPERATOR,CREATE TYPE,CREATE TRIGGER,CREATE INDEXTYPE,CREATE PROCEDURE,CREATE SEQUENCE,CREATE VIEW,CREATE MATERIALIZED VIEW.

Pma back-to-top icon.png Back to Data Migration Paths



Originating version 8.5.101.17
Target version 8.5.101.21
Script to migrate to the target version from the original version advisors-platform-migrateSchema_8.5.101.17_8.5.101.21.sql
AGA schema dependencies

Before you apply the Platform migration script, migrate the AGA metrics schema to the target version by connecting as the AGA metrics schema owner and running any gc_metrics_<targetversion>_Objectsxxx.sql script for Oracle or gc_metrics_db_<target version>.sql script for MSSQL Server installations. There is no need to drop any AGA metrics objects before applying the script. Once the corresponding script is applied, in Oracle installations grant select privileges to the Platform schema owner as follows:

GRANT SELECT ON AGENT_SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON CALL_TYPE TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON CALL_TYPE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON CONTROLLER_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON INTERACTION_QUEUE TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON INTERACTION_QUEUE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON LOGICAL_INTERFACE_CONTROLLER TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON PERIPHERAL TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON PERIPHERAL_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON QUEUE_SET1_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON QUEUE_SET2_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SERVICE TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SERVICE_MEMBER TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SERVICE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SKILL_GROUP TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;

Proceed to the Platform schema migration.

Platform schema migration specifics

In Oracle installations, before the Platform migration script is applied, ask your DBA to verify that the Platform schema owner is granted the following privileges:

CREATE SESSION,CREATE TABLE,CREATE OPERATOR,CREATE TYPE,CREATE TRIGGER,CREATE INDEXTYPE,CREATE PROCEDURE,CREATE SEQUENCE,CREATE VIEW,CREATE MATERIALIZED VIEW, CREATE JOB, EXECUTE ON SYS.GENADVISORSJOBCLASS.

Pma back-to-top icon.png Back to Data Migration Paths



Originating version 8.5.101.21
Target version 8.5.102.00
Script to migrate to the target version from the original version advisors-platform-migrateSchema_8.5.101.09_8.5.102.00.sql
AGA schema dependencies

Before you apply the Platform migration script, migrate the AGA metrics schema to the target version by connecting as the AGA metrics schema owner and running any gc_metrics_<targetversion>_Objectsxxx.sql script for Oracle or gc_metrics_db_<target version>.sql script for MSSQL Server installations. There is no need to drop any AGA metrics objects before applying the script. Once the corresponding script is applied, in Oracle installations grant select privileges to the Platform schema owner as follows:

GRANT SELECT ON AGENT_SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON CALL_TYPE TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON CALL_TYPE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON CONTROLLER_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON INTERACTION_QUEUE TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON INTERACTION_QUEUE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON LOGICAL_INTERFACE_CONTROLLER TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON PERIPHERAL TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON PERIPHERAL_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON QUEUE_SET1_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON QUEUE_SET2_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SERVICE TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SERVICE_MEMBER TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SERVICE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SKILL_GROUP TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;

Proceed to the Platform schema migration.

Platform schema migration specifics

In Oracle installations, before the Platform migration script is applied, ask your DBA to verify that the Platform schema owner is granted the following privileges:

CREATE SESSION,CREATE TABLE,CREATE OPERATOR,CREATE TYPE,CREATE TRIGGER,CREATE INDEXTYPE,CREATE PROCEDURE,CREATE SEQUENCE,CREATE VIEW,CREATE MATERIALIZED VIEW, CREATE JOB, EXECUTE ON SYS.GENADVISORSJOBCLASS.

Pma back-to-top icon.png Back to Data Migration Paths



Originating version 8.5.101.21 or 8.5.102.00
Target version 8.5.201.26
Tip
Advisors release 8.5.201.26 is included in the migration path for those who might have installed this version (it was a restricted-access release). If you did not install release 8.5.201.26 in your environment, then you can omit this migration step.
Script to migrate to the target version from the original version advisors-platform-migrateSchema_8.5.101(102)_8.5.201.26.sql
AGA schema dependencies

Before you apply the Platform migration script, migrate the AGA metrics schema to the target version by connecting as the AGA metrics schema owner and running any gc_metrics_<targetversion>_Objectsxxx.sql script for Oracle or gc_metrics_db_<target version>.sql script for MSSQL Server installations. There is no need to drop any AGA metrics objects before applying the script. Once the corresponding script is applied, in Oracle installations grant select privileges to the Platform schema owner as follows:

GRANT SELECT ON AGENT_SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON CALL_TYPE TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON CALL_TYPE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON CONTROLLER_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON INTERACTION_QUEUE TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON INTERACTION_QUEUE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON LOGICAL_INTERFACE_CONTROLLER TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON PERIPHERAL TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON PERIPHERAL_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON QUEUE_SET1_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON QUEUE_SET2_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SERVICE TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SERVICE_MEMBER TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SERVICE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SKILL_GROUP TO &&PLATFORM_SCHEMA_OWNER;
GRANT SELECT ON SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER;

Proceed to the Platform schema migration.

Platform schema migration specifics

In Oracle installations, before the migration script is applied, ask your DBA to verify that the Platform schema owner is granted the following privileges:

CREATE SESSION,CREATE TABLE,CREATE OPERATOR,CREATE TYPE,CREATE TRIGGER,CREATE INDEXTYPE,CREATE PROCEDURE,CREATE SEQUENCE,CREATE VIEW,CREATE MATERIALIZED VIEW, CREATE JOB, EXECUTE ON SYS.GENADVISORSJOBCLASS.

Pma back-to-top icon.png Back to Data Migration Paths



Originating version 8.5.101.21, 8.5.102.00, or 8.5.201.26
Target version 8.5.202.09
Script to migrate to the target version from the original version advisors-platform-migrateSchema_8.5.101(102)_8.5.202.09.sql
AGA schema dependencies

Before you apply the Platform migration script, migrate the AGA metrics schema to the target version by connecting as the AGA metrics schema owner and running any gc_metrics_<targetversion>_Objectsxxx.sql script for Oracle or gc_metrics_db_<target version>.sql script for MSSQL Server installations. There is no need to drop any AGA metrics objects before applying the script. Once the corresponding script is applied, in Oracle installations grant select privileges to the Platform schema owner as follows:

GRANT SELECT ON AGENT_SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON CALL_TYPE TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON CALL_TYPE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON CONTROLLER_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON INTERACTION_QUEUE TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON INTERACTION_QUEUE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON LOGICAL_INTERFACE_CONTROLLER TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON PERIPHERAL TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON PERIPHERAL_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON QUEUE_SET1_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON QUEUE_SET2_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SERVICE TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SERVICE_MEMBER TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SERVICE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SKILL_GROUP TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;

Platform schema migration specifics
  1. In Oracle installations, before the migration script is applied, ask your DBA to verify that the Platform schema owner is granted the following privileges:
    CREATE SESSION,CREATE TABLE,CREATE OPERATOR,CREATE TYPE,CREATE TRIGGER,CREATE INDEXTYPE,CREATE PROCEDURE,CREATE SEQUENCE,CREATE VIEW,CREATE MATERIALIZED VIEW, CREATE JOB, EXECUTE ON SYS.GENADVISORSJOBCLASS.
  2. Before you run the script, ask your DBA to determine if your Oracle server has JServer Java Virtual Machine installed. If not, ask your DBA to grant the EXECUTE ON SYS.DBMS_LOCK privilege to the Platform schema owner. In this case, use the migration script located under oracleNoJServer folder.
  3. If you do not plan to set up Oracle enhanced security that allows the application to connect to the database as an application user with minimum privileges, you will need to edit the migration script before it is applied by replacing all entries of DEFINER with CURRENT_USER, or you can request the edited script through Genesys support.
  4. Note that switching from NoJServer version back to Jserver will require removing the spWaitSec procedure from the Platform procedure list and then running the migration script contained in the root folder. Switching from the JServer version back to NoJserver will require removing the spWaitMSec procedure from the Platform procedure list and then running the migration script contained in the root folder.
  5. If you plan to set up Oracle enhanced security for Advisors, ask your DBA to review and apply the advisors-platform-<targetversion>_UsersAndRoles.sql script after the Platform migration script is applied by its schema owner. For more information, see enhanced security setup.

Pma back-to-top icon.png Back to Data Migration Paths



Originating version 8.5.202.09
Target version 8.5.202.10
Script to migrate to the target version from the original version None
AGA schema dependencies

Before you apply the Platform migration script, migrate the AGA metrics schema to the target version by connecting as the AGA metrics schema owner and running any gc_metrics_<targetversion>_Objectsxxx.sql script for Oracle or gc_metrics_db_<target version>.sql script for MSSQL Server installations. There is no need to drop any AGA metrics objects before applying the script. Once the corresponding script is applied, in Oracle installations grant select privileges to the Platform schema owner as follows:

GRANT SELECT ON AGENT_SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON CALL_TYPE TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON CALL_TYPE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON CONTROLLER_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON INTERACTION_QUEUE TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON INTERACTION_QUEUE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON LOGICAL_INTERFACE_CONTROLLER TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON PERIPHERAL TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON PERIPHERAL_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON QUEUE_SET1_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON QUEUE_SET2_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SERVICE TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SERVICE_MEMBER TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SERVICE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SKILL_GROUP TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;

If you decide to apply the Platform migration script, make sure that the step with AGA metrics migration is implemented first.

Platform schema migration specifics If you have already migrated the Platform schema to release 8.5.202.09, no migration scripts need to be applied to the Platform schema during migration to release 8.5.202.10. If you imported the database or want to change something – for example, you want to switch from Jserver to NoJserver version or vice versa – repeat the instructions shown in the table for the 8.5.202.09 target version and use the 8.5.202.09 scripts. Do not use the database scripts that were supplied with the Platform distribution for Hot Fix release 8.5.202.10.

Pma back-to-top icon.png Back to Data Migration Paths



Originating version 8.5.202.10 or 8.5.202.09
Target version 9.0.000.06
Script to migrate to the target version from the original version advisors-platform-migrateSchema_8.5.202.09_9.0.000.06.sql
AGA schema dependencies

Before you apply the Platform migration script, migrate the AGA metrics schema to the target version by connecting as the AGA metrics schema owner and running any gc_metrics_<targetversion>_Objectsxxx.sql script for Oracle or gc_metrics_db_<target version>.sql script for MSSQL Server installations. There is no need to drop any AGA metrics objects before applying the script. Once the corresponding script is applied, in Oracle installations grant select privileges to the Platform schema owner as follows:

GRANT SELECT ON AGENT_SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON CALL_TYPE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON CONTROLLER_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON INTERACTION_QUEUE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON PERIPHERAL_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON QUEUE_SET1_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON QUEUE_SET2_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SERVICE_MEMBER TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SERVICE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;

Platform schema migration specifics
  1. In Oracle installations, before the migration script is applied, ask your DBA to verify that the Platform schema owner is granted the following privileges:
    CREATE SESSION,CREATE TABLE,CREATE OPERATOR,CREATE TYPE,CREATE TRIGGER,CREATE INDEXTYPE,CREATE PROCEDURE,CREATE SEQUENCE,CREATE VIEW,CREATE MATERIALIZED VIEW, CREATE JOB, EXECUTE ON SYS.GENADVISORSJOBCLASS.
  2. Before you run the script, ask your DBA to determine if your Oracle server has JServer Java Virtual Machine installed. If not, ask your DBA to grant the EXECUTE ON SYS.DBMS_LOCK privilege to the Platform schema owner. In this case, use the migration script located under the oracleNoJServer folder. Before running the script, expand the procedures folder in your Platform schema and remove the spWaitMsec procedure if it is there.
  3. If you do not plan to set up Oracle enhanced security that allows the application to connect to the database as an application user with minimum privileges, you will need to edit the chosen migration script before it is applied by replacing all entries of DEFINER with CURRENT_USER, or you can request the edited script through Genesys support.
  4. Note that switching from the NoJServer version back to Jserver will require removing the spWaitSec procedure from the Platform procedure list and then running the migration script contained in the root folder. Switching from the JServer version back to NoJserver will require removing the spWaitMSec procedure from the Platform procedure list and then running the migration script contained in the root folder.
  5. For Oracle installations, a bulk configuration/export tool for the independent configuration mode is available as a separate installation script. Contact Genesys Support to request this script.
    The format of bulk configuration structures in the release 9.0.002.09 bulk configuration tool has changed: the concatenated application and agent group names are no longer used and the parts related to tenant name, switch name, and filter are now recorded in separate fields. Moreover, if an object is unique within a switch or tenant, then the switch and tenant details are optional. You can still upload your bulk configuration files that contain data in the old name format, and then use the bulk configuration script to transform the format to the new one. The advisors-platform-version_BulkConfigurationTool.sql script will transform the old format to the new if the specified switch names and filter names are already imported into the Platform database. Re-applying the advisors-platform-version_BulkConfigurationTool.sql script does not erase any data. It is safe to apply the advisors-platform-version_BulkConfigurationTool.sql and blkCfgExp.sql scripts while the application is up and running.
  6. If you plan to set up Oracle enhanced security for Advisors, ask your DBA to review and apply the advisors-platform-<targetversion>_UsersAndRoles.sql script after the Platform migration script is applied by its schema owner. For more information, see enhanced security setup.

Pma back-to-top icon.png Back to Data Migration Paths



Originating version 9.0.000.06 or 8.5.202.09
Target version 9.0.000.10
Script to migrate to the target version from the original version advisors-platform-migrateSchema_8.5.202.09_9.0.000.10.sql
AGA schema dependencies

Before you apply the Platform migration script, migrate the AGA metrics schema to the target version by connecting as the AGA metrics schema owner and running any gc_metrics_<targetversion>_Objectsxxx.sql script for Oracle or gc_metrics_db_<target version>.sql script for MSSQL Server installations. There is no need to drop any AGA metrics objects before applying the script. Once the corresponding script is applied, in Oracle installations grant select privileges to the Platform schema owner as follows:

GRANT SELECT ON AGENT_SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON CALL_TYPE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON CONTROLLER_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON INTERACTION_QUEUE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON PERIPHERAL_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON QUEUE_SET1_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON QUEUE_SET2_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SERVICE_MEMBER TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SERVICE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;

Platform schema migration specifics
  1. In Oracle installations, before the migration script is applied, ask your DBA to verify that the Platform schema owner is granted the following privileges:
    CREATE SESSION,CREATE TABLE,CREATE OPERATOR,CREATE TYPE,CREATE TRIGGER,CREATE INDEXTYPE,CREATE PROCEDURE,CREATE SEQUENCE,CREATE VIEW,CREATE MATERIALIZED VIEW, CREATE JOB, EXECUTE ON SYS.GENADVISORSJOBCLASS.
  2. Before you run the script, ask your DBA to determine if your Oracle server has JServer Java Virtual Machine installed. If not, ask your DBA to grant the EXECUTE ON SYS.DBMS_LOCK privilege to the Platform schema owner. In this case, use the migration script located under the oracleNoJServer folder.
  3. If you do not plan to set up Oracle enhanced security that allows the application to connect to the database as an application user with minimum privileges, you will need to edit the migration script before it is applied by replacing all entries of DEFINER with CURRENT_USER, or you can request the edited script through Genesys support.
  4. Note that switching from the NoJServer version back to Jserver will require removing the spWaitSec procedure from the Platform procedure list and then running the migration script contained in the root folder. Switching from the JServer version back to NoJserver will require removing the spWaitMSec procedure from the Platform procedure list and then running the migration script contained in the root folder.
  5. For Oracle installations, a bulk configuration/export tool for the independent configuration mode is available as a separate installation script. Contact Genesys Support to request this script.
    The format of bulk configuration structures in the release 9.0.002.09 bulk configuration tool has changed: the concatenated application and agent group names are no longer used and the parts related to tenant name, switch name, and filter are now recorded in separate fields. Moreover, if an object is unique within a switch or tenant, then the switch and tenant details are optional. You can still upload your bulk configuration files that contain data in the old name format, and then use the bulk configuration script to transform the format to the new one. The advisors-platform-version_BulkConfigurationTool.sql script will transform the old format to the new if the specified switch names and filter names are already imported into the Platform database. Re-applying the advisors-platform-version_BulkConfigurationTool.sql script does not erase any data. It is safe to apply the advisors-platform-version_BulkConfigurationTool.sql and blkCfgExp.sql scripts while the application is up and running.
  6. If you plan to set up Oracle enhanced security for Advisors, ask your DBA to review and apply the advisors-platform-<targetversion>_UsersAndRoles.sql script after the Platform migration script is applied by its schema owner. For more information, see enhanced security setup.

Pma back-to-top icon.png Back to Data Migration Paths



Originating version 9.0.000.10
Target version 9.0.001.06
Script to migrate to the target version from the original version advisors-platform-migrateSchema_9.000.10(7,6)_9.0.001.06.sql
AGA schema dependencies

If an AGA metrics schema upgrade was done in the previous release, you can skip it in the migration to 9.0.001.06. If you moved the schemas to another database or cloned them with different names, you will need to reinstate all privileges. In Oracle installations, reinstate select privileges to the Platform schema owner to AGA metrics views as follows:

GRANT SELECT ON AGENT_SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON CALL_TYPE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON CONTROLLER_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON INTERACTION_QUEUE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON PERIPHERAL_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON QUEUE_SET1_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON QUEUE_SET2_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SERVICE_MEMBER TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SERVICE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;

Platform schema migration specifics
  1. In Oracle installations, before the migration script is applied, ask your DBA to verify that the Platform schema owner is granted the following privileges:
    CREATE SESSION,CREATE TABLE,CREATE OPERATOR,CREATE TYPE,CREATE TRIGGER,CREATE INDEXTYPE,CREATE PROCEDURE,CREATE SEQUENCE,CREATE VIEW,CREATE MATERIALIZED VIEW, CREATE JOB, EXECUTE ON SYS.GENADVISORSJOBCLASS.
  2. Before you run the script, ask your DBA to determine if your Oracle server has JServer Java Virtual Machine installed. If not, ask your DBA to grant the EXECUTE ON SYS.DBMS_LOCK privilege to the Platform schema owner.
  3. If you do not plan to set up Oracle enhanced security that allows the application to connect to the database as an application user with minimum privileges, you will need to edit the migration script before it is applied by replacing all entries of DEFINER with CURRENT_USER, or you can request the edited script through Genesys support.
  4. If you have the bulk configuration tool installed, apply the advisors-platform-9.0.002.09_BulkConfigurationTool.sql script, which you can find in the ip\platform-database-sql\oracle\bulkconfig folder of the Platform release 9.0.002.09 installation package. If you do not have the release 9.0.002.09 installation package, request the script from Genesys Support team.
  5. If you plan to set up Oracle enhanced security for Advisors, ask your DBA to review and apply the advisors-platform-<targetversion>_UsersAndRoles.sql script after the Platform migration script is applied by its schema owner. For more information, see enhanced security setup.
  6. If you are planning to use the Advisors bulk configuration/export tool in your installation with Oracle, execute the advisors-platform-9.0.002.09_BulkConfigurationTool.sql script against the Platform schema. The advisors-platform-9.0.002.09_BulkConfigurationTool.sql script and the matching blkCfgExp.sql script can be requested from your Genesys Support representative. There is only one blkCfgExp.sql script for any mode. The script detects the configuration mode automatically and populates the corresponding tables. All bulk configuration tables are present in the schema, but only the ones that correspond to the selected configuration mode are considered.
    The format of bulk configuration structures in the release 9.0.002.09 bulk configuration tool has changed: the concatenated application and agent group names are no longer used and the parts related to tenant name, switch name, and filter are now recorded in separate fields. Moreover, if an object is unique within a switch or tenant, then the switch and tenant details are optional. You can still upload your bulk configuration files that contain data in the old name format, and then use the bulk configuration script to transform the format to the new one. The advisors-platform-version_BulkConfigurationTool.sql script will transform the old format to the new if the specified switch names and filter names are already imported into the Platform database. Re-applying the advisors-platform-version_BulkConfigurationTool.sql script does not erase any data. It is safe to apply the advisors-platform-version_BulkConfigurationTool.sql and blkCfgExp.sql scripts while the application is up and running.
    Important
    The bulk configuration/export tool for independent mode is not available for installations with MS SQL Server starting with release 9.0.001.06.
  7. In this release (release 9.0.001.06), you must run the advisors-platform-<targetversion>_ValidateDatabaseInstall.sql script as the schema owner after you install XML Generator and before you start it.

Pma back-to-top icon.png Back to Data Migration Paths



Originating version 9.0.001.06
Target version 9.0.002.03
Script to migrate to the target version from the original version advisors-platform-migrateSchema_9.001.06_9.0.002.03.sql
AGA schema dependencies

Before you apply the Platform migration script, migrate the AGA metrics schema to 9.0.002.03 by connecting as the AGA metrics schema owner and running any gc_metrics_<target version>_Objectsxxx.sql script. There is no need to drop any AGA metrics objects. Once this is done, grant select privileges to the Platform schema owner as follows:

GRANT SELECT ON AGENT_SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON CALL_TYPE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON CONTROLLER_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON INTERACTION_QUEUE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON PERIPHERAL_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON QUEUE_SET1_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON QUEUE_SET2_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SERVICE_MEMBER TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SERVICE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;

Platform schema migration specifics
  1. In Oracle installations, before the migration script is applied, ask your DBA to verify that the Platform schema owner is granted the following privileges:
    CREATE SESSION,CREATE TABLE,CREATE OPERATOR,CREATE TYPE,CREATE TRIGGER,CREATE INDEXTYPE,CREATE PROCEDURE,CREATE SEQUENCE,CREATE VIEW,CREATE MATERIALIZED VIEW, CREATE JOB, EXECUTE ON SYS.GENADVISORSJOBCLASS.
  2. Before you run the script, ask your DBA to determine if your Oracle server has JServer Java Virtual Machine installed. If not, ask your DBA to grant the EXECUTE ON SYS.DBMS_LOCK privilege to the Platform schema owner. Otherwise, use a script located under the oracleJServer folder.
  3. If you have the bulk configuration tool installed, apply the advisors-platform-9.0.002.09_BulkConfigurationTool.sql script, which you can find in the ip\platform-database-sql\oracle\bulkconfig folder of the Platform release 9.0.002.09 installation package. If you do not have the release 9.0.002.09 installation package, request the script from Genesys Support team.
  4. If you do not plan to set up Oracle enhanced security that allows the application to connect to the database as an application user with minimum privileges, you will need to use the script located under the current_user subfolder. Otherwise, use the script located under the definer subfolder. In this case, ask your DBA to review and apply the advisors-platform-<targetversion>_UsersAndRoles.sql script after the Platform migration script is applied by its schema owner. For more information, see enhanced security setup.
  5. If you are planning to use the Advisors bulk configuration/export tool in your installation with Oracle, execute the advisors-platform-9.0.002.09_BulkConfigurationTool.sql script against the Platform schema. The advisors-platform-9.0.002.09_BulkConfigurationTool.sql script and the matching blkCfgExp.sql script can be requested from your Genesys Support representative. There is only one blkCfgExp.sql script for any mode. The script detects the configuration mode automatically and populates the corresponding tables. All bulk configuration tables are present in the schema, but only the ones that correspond to the selected configuration mode are considered.
    The format of bulk configuration structures in the release 9.0.002.09 bulk configuration tool has changed: the concatenated application and agent group names are no longer used and the parts related to tenant name, switch name, and filter are now recorded in separate fields. Moreover, if an object is unique within a switch or tenant, then the switch and tenant details are optional. You can still upload your bulk configuration files that contain data in the old name format, and then use the bulk configuration script to transform the format to the new one. The advisors-platform-version_BulkConfigurationTool.sql script will transform the old format to the new if the specified switch names and filter names are already imported into the Platform database. Re-applying the advisors-platform-version_BulkConfigurationTool.sql script does not erase any data. It is safe to apply the advisors-platform-version_BulkConfigurationTool.sql and blkCfgExp.sql scripts while the application is up and running.
    Important
    The bulk configuration/export tool for independent mode is not available for installations with MS SQL Server starting with release 9.0.001.06.
  6. In this release (release 9.0.002.03), you will need to run the advisors-platform-<targetversion>_ValidateDatabaseInstall.sql script as the schema owner after you install XML Generator and before you start it.

Pma back-to-top icon.png Back to Data Migration Paths



Originating version 9.0.002.03
Target version 9.0.002.09
Script to migrate to the target version from the original version advisors-platform-migrateSchema_9.002.03-9.0.002.09.sql
AGA schema dependencies

Before you apply the Platform migration script, migrate the AGA metrics schema to 9.0.002.09 by connecting as the AGA metrics schema owner and running any gc_metrics_<target version>_Objectsxxx.sql script. There is no need to drop any AGA metrics objects. Once this is done, grant select privileges to the Platform schema owner as follows:

GRANT SELECT ON AGENT_SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON CALL_TYPE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON CONTROLLER_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON INTERACTION_QUEUE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON PERIPHERAL_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON QUEUE_SET1_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON QUEUE_SET2_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SERVICE_MEMBER TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SERVICE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;

Platform schema migration specifics
  1. In Oracle installations, before the migration script is applied, ask your DBA to verify that the Platform schema owner is granted the following privileges:
    CREATE SESSION,CREATE TABLE,CREATE OPERATOR,CREATE TYPE,CREATE TRIGGER,CREATE INDEXTYPE,CREATE PROCEDURE,CREATE SEQUENCE,CREATE VIEW,CREATE MATERIALIZED VIEW, CREATE JOB, EXECUTE ON SYS.GENADVISORSJOBCLASS.
  2. Before you run the script, ask your DBA to determine if your Oracle server has JServer Java Virtual Machine installed. If not, ask your DBA to grant the EXECUTE ON SYS.DBMS_LOCK privilege to the Platform schema owner. Otherwise, use a script located under the oracleJServer folder.
  3. If you do not plan to set up Oracle enhanced security that allows the application to connect to the database as an application user with minimum privileges, you will need to use the script located under the current_user subfolder. Otherwise, use the script located under the definer subfolder. In this case, ask your DBA to review and apply the advisors-platform-<targetversion>_UsersAndRoles.sql script after the Platform migration script is applied by its schema owner. For more information, see enhanced security setup.
  4. For Oracle installations, a bulk configuration/export tool for the independent configuration mode is available starting with Advisors release 9.0.002.09. The tool is included with the deployment/migration scripts.
    The format of bulk configuration structures in the release 9.0.002.09 bulk configuration tool has changed: the concatenated application and agent group names are no longer used and the parts related to tenant name, switch name, and filter are now recorded in separate fields. Moreover, if an object is unique within a switch or tenant, then the switch and tenant details are optional.
    Important
    The bulk configuration/export tool for independent mode is not available for installations with MS SQL Server starting with release 9.0.001.06.
  5. In this release, you will need to run the advisors-platform-<targetversion>_ValidateDatabaseInstall.sql script as the schema owner after you install XML Generator and before you start it.
Metric Graphing schema migration specifics Contact Customer Care to request the metric-graphing-database_9.0.002.09_patch1.sql script. Apply the script to the metric graphing schema after you have applied the metric graphing migration script. See the Known Issues in the Contact Center Advisor and Workforce Advisor Release Note.

Pma back-to-top icon.png Back to Data Migration Paths



Originating version 9.0.002.09
Target version 9.0.003.04
Scripts to migrate to the target version from the original version
  1. advisors-platform-migrateSchema_9.002.09_9.0.003.04.sql
  2. advisors-platform-9.0.003.04_BulkConfigurationTool.sql (Oracle only)
  3. advisors-platform-9.0.003.04_patch1.sql (Oracle only)
AGA schema dependencies

Before you apply the Platform migration script, migrate the AGA metrics schema to 9.0.003.04 by connecting as the AGA metrics schema owner and running any gc_metrics_<target version>_Objectsxxx.sql script. There is no need to drop any AGA metrics objects. Once this is done, grant select privileges to the Platform schema owner as follows:

GRANT SELECT ON AGENT_SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON CALL_TYPE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON CONTROLLER_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON INTERACTION_QUEUE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON PERIPHERAL_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON QUEUE_SET1_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON QUEUE_SET2_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SERVICE_MEMBER TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SERVICE_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;
GRANT SELECT ON SKILL_GROUP_REAL_TIME TO &&PLATFORM_SCHEMA_OWNER WITH GRANT OPTION;

Platform schema migration specifics
  1. In Oracle installations, before the migration script is applied, ask your DBA to verify that the Platform schema owner is granted the following privileges:
    CREATE SESSION,CREATE TABLE,CREATE OPERATOR,CREATE TYPE,CREATE TRIGGER,CREATE INDEXTYPE,CREATE PROCEDURE,CREATE SEQUENCE,CREATE VIEW,CREATE MATERIALIZED VIEW, CREATE JOB, EXECUTE ON SYS.GENADVISORSJOBCLASS.
  2. Before you run the script, ask your DBA to determine if your Oracle server has JServer Java Virtual Machine installed. If not, ask your DBA to grant the EXECUTE ON SYS.DBMS_LOCK privilege to the Platform schema owner. In this case, use the migration script located under the oracleNoJServer folder. Otherwise, use a script located under the oracleJServer folder.
  3. If you do not plan to set up Oracle enhanced security that allows the application to connect to the database as an application user with minimum privileges, you will need to use the migration script and the patch script located under the current_user subfolder. Otherwise, use the scripts located under the definer subfolder. In this case, ask your DBA to review and apply the advisors-platform-<targetversion>_UsersAndRoles.sql script after the Platform migration script and the patch script are applied by its schema owner. For more information, see enhanced security setup.
  4. Apply advisors-platform-migrateSchema_9.002.09_9.0.003.04.sql.
  5. In Oracle installations, apply advisors-platform-9.0.003.04_BulkConfigurationTool.sql to upgrade the bulk configuration tool.
  6. In Oracle installations, apply advisors-platform-9.0.003.04_patch1.sql.
  7. In Oracle installations, and only if you use the Oracle enhanced security setup, apply the advisors-platform-<targetversion>_UsersAndRoles.sql script. In MSSQL installations, and only if you use MSSQL enhanced security setup, execute spGrantExecute in each database.
  8. In this release, you must run the advisors-platform-<targetversion>_ValidateDatabaseInstall.sql script as the Oracle Platform schema owner after you install XML Generator and before you start it.

Pma back-to-top icon.png Back to Data Migration Paths

This page was last edited on January 25, 2019, at 02:52.

Feedback

Comment on this article:

blog comments powered by Disqus