Appendix: Converting PeopleSoft Systems to Unicode Databases

This appendix discusses:

Click to jump to parent topicUnderstanding Converting PeopleSoft Systems to Unicode Databases

PeopleSoft can manage data in many languages in a single database by using Unicode. The Unicode Standard, published by The Unicode Consortium, and synchronized with the International Standard ISO 10646, provides a character set that can support all the characters needed to write virtually every business language in use today.

By creating a PeopleSoft database using Unicode, you can maintain application data, reports, user interface components, and other linguistic elements of your PeopleSoft system in as many languages as you want, all in a single database.

Creating a Unicode database will be of benefit to your organization if you plan on maintaining multiple languages in your PeopleSoft system, or if one or more of the languages you are using are non-Western European languages.

Click to jump to parent topicUnderstanding Planning Unicode Conversions

This section describes considerations to take into account when planning to convert to a Unicode database.

Click to jump to top of pageClick to jump to parent topicPlatform Support

Unicode data storage is currently supported on the following PeopleSoft database platforms:

For specific versions or required patches for these database platforms, see the PeopleTools 8.51 Hardware and Software Requirements book for your PeopleTools release.

Unix and Microsoft Windows editions of the PeopleSoft application server support Unicode. There are no special settings or configuration options you need to set to enable this support.

SQR may be bundled with your PeopleSoft applications. This version of SQR is Unicode-enabled, however it may require some settings to be defined in the PSSQR.INI (or PSSQR.UNX) file for SQR to correctly read and write files in Unicode.

Click to jump to top of pageClick to jump to parent topicDatabase Sizing

When planning to convert to a Unicode database consider the impact on the physical size of your data.

Depending on the transformation of Unicode that your database platform uses and the mix of languages you plan to use in the PeopleSoft database, you can expect to see the database grow. A red paper on Unicode database sizing is available at http://www.peoplesoft.com/media/en/pdf/red_paper_unicode.pdf

Click to jump to top of pageClick to jump to parent topicCoexistence of Unicode and Non-Unicode Databases

PeopleSoft supports the coexistence of Unicode and non-Unicode databases in a single implementation. Should you need to maintain databases in both Unicode and non-Unicode character sets, most PeopleSoft utilities and commands can operate across both databases seamlessly.

Depending on the character set of the non-Unicode database, some character data may be lost when transferring data between databases. For example, if you load data from a Unicode Japanese and English database into a Latin-1 non-Unicode database, the English data will load correctly, but the Japanese characters will be lost and converted into replacement characters such as question marks.

Although it is easy to have Unicode and non-Unicode databases co-exist, you will need to maintain two separate PeopleSoft file server and batch server environments for each database type, because the COBOL code supplied with some PeopleSoft applications differs significantly between Unicode and non-Unicode databases. Therefore, if you will be maintaining Unicode and non-Unicode databases and you require COBOL, you will need to install the PeopleTools and application CDs twice, and answer the question about Unicode during each installation appropriately

Data Mover

DAT files created by Data Mover are always encoded in Unicode. Data Mover can read these Unicode DAT files and load their contents into either Unicode or non-Unicode database. When creating a new Unicode database, ensure that the Data Mover command SET UNICODE ON is issued before the IMPORT * command.

Upgrade Compare/Copy

Upgrade Compare and Upgrade Copy supports copying objects between Unicode and non-Unicode databases. There are no restrictions on the source and target database character sets.

Cache Files

Cache files on the PeopleSoft application server are always stored in Unicode format. If you rebuild your non-Unicode database as a Unicode database, you can still use the cache files you may have pre-loaded on the application server.

SQR

On database platforms supporting Unicode, SQR always connects to the database using a Unicode character set via the database vendor’s API. Therefore, you can use SQR to copy data to and from Unicode and non-Unicode databases. When writing and reading files with SQR, you can select the character set that should be used to encode the file using the ENCODING parameter to the SQR OPEN command.

Click to jump to parent topicConverting to Unicode on Oracle Databases

This section provides an overview of converting to Unicode on an Oracle database and discusses how to:

Click to jump to top of pageClick to jump to parent topicUnderstanding Converting PeopleSoft 8.x Systems on Oracle Databases to Unicode

Converting a PeopleSoft system on an Oracle database to Unicode requires creating a new Oracle instance with a Unicode character set. If your current database uses byte semantics (typical for PeopleSoft 8.9 applications or earlier), you must also create new column sizes for PeopleSoft columns created as VARCHAR2.

Note. The AL32UTF8 character set is the preferred character set for the Oracle database. However, the UTF8 character set is also supported.

For small databases, the simplest way of converting a PeopleSoft database on Oracle to Unicode is to export the entire database using PeopleSoft Data Mover, create a new Oracle instance using a Unicode character set, and re-import the entire database using PeopleSoft Data Mover. The details of this process are not provided in this appendix.

For larger databases, a better process is to use PeopleSoft Data Mover to pre-build the structure of the PeopleSoft tables and then use Oracle database utilities to move the bulk of the data between the old and new Oracle instances. The details of these processes are provided in this appendix.

If you use this process, you have two different sets of Oracle utilities you can use to export and import the database content:

Instructions for each utility are documented in this appendix.

Click to jump to top of pageClick to jump to parent topicExporting PeopleSoft Table Structures Using PeopleSoft Data Mover

This section describes how to use PeopleSoft Data Mover to export the PeopleSoft database structure to a DAT file.

Note. This process exports the database table structure only and does not include the database contents.

Sign into the PeopleSoft database using PeopleSoft Data Mover in non-bootstrap mode, and run the following script.

SET NO TRACE;
SET OUTPUT ​output_file;
SET NO DATA;
EXPORT *;

The DAT file created by PeopleSoft Data Mover will not be large—possibly 20-30 MB, as it will contain only the structure of your PeopleSoft tables, views and indexes—not the data.

Save the file created by this process. It will be referred to as the structural export in this appendix.

Click to jump to top of pageClick to jump to parent topicExporting Database Contents

This section provides an overview of exporting database contents and discusses how to:

Understanding Exporting Database Contents

You have two different sets of Oracle utilities you can use to export and import the database content:

Important! Ensure that you follow only the instructions for the pair of utilities that you have chosen to use.

Setting the NLS_LANG Variable

Before running the export process, verify that the character set specified by NLS_LANG is set to match the character set of the database. NLS_LANG is an environment variable on Unix and a registry setting under HKEY_LOCAL_MACHINE\Software\Oracle on Microsoft Windows.

To verify the current character set of the Oracle database, sign in the Oracle SQL utility of your choice as the database administrator. Then, execute the following SQL statement:

SELECT VALUE FROM SYS.V_$NLS_PARAMETERS
WHERE PARAMETER = 'NLS_CHARACTERSET';

For example, if the database character set is WE8ISO8859P1, NLS_LANG should be set to AMERICAN_AMERICA.WE8ISO8859P1, or another language combination with WE8ISO8859P1 as the character set.

Creating and Running the Export Preparation Script for Oracle Data Pump

After you have set the NLS_LANG environment variable appropriately based on your instance’s current character set, create an export preparation script similar to the following example, substituting the location and name of the export file to be created.

You can use any text editor to create this export preparation script, which will be referred to as expdp_prep.sql in this document. Enter the following commands in expdp_prep.sql:

CREATE DIRECTORY DMPDIR AS 'D:\temp\ConvDBAnsiToUnicode';
GRANT READ, WRITE ON DIRECTORY DMPDIR TO system;
SET SERVEROUTPUT ON;

Note. Ensure that the file system on which you will be creating the export file has sufficient space available to accommodate all the data in the PeopleSoft database. A good estimate of the space needed is to calculate the amount of space currently taken by tables owned by the PeopleSoft owner ID and adding 20 percent. You can get this data from querying the DBA_FREE_SPACE and DBA_DATA_FILES catalog views. Remember that index data is not stored in export files, only the index definition. If you have insufficient space on any one file system to store the export file, you can use the filesize parameter of the Oracle Export utility. See your Oracle utilities guide for more information on multi-file exports.

Sign into the Oracle SQL utility of your choice as the database administrator. Run the expdp_prep.sql script .

Exporting Database Contents Using Oracle Data Pump

After running the expdp_prep.sql script as described in the previous section, create an export script.

You can use any text editor to create an export script similar to the following example, which will be referred to as expdp_export.sql in this document. Enter the following commands in expdp_export.sql:

DECLARE
  ind NUMBER;              -- Loop index
  h1 NUMBER;               -- Data Pump job handle
  percent_done NUMBER;     -- Percentage of job complete
  job_state VARCHAR2(30);  -- To keep track of job state
  le ku$_LogEntry;         -- For WIP and error messages
  js ku$_JobStatus;        -- The job status from get_status
  jd ku$_JobDesc;          -- The job description from get_status
  sts ku$_Status;          -- The status object returned by get_status
BEGIN

-- Create a (user-named) Data Pump job to do a schema export.
--  h1 := DBMS_DATAPUMP.OPEN('EXPORT','SCHEMA',NULL,'PTTEMP01','LATEST');

  h1 := DBMS_DATAPUMP.OPEN ('EXPORT', 'FULL', NULL, 'EXPATOU', 'LATEST');


-- Specify a single dump file for the job (using the handle just returned)
-- and a directory object, which must already be defined and accessible
-- to the user running this procedure.

  DBMS_DATAPUMP.ADD_FILE(h1,'dataPumpDBExport.dmp','DMPDIR');

-- A metadata filter is used to specify the schema that will be exported.

-- *** DBMS_DATAPUMP.METADATA_FILTER(h1,'SCHEMA_EXPR','IN (''HR'')');

-- Start the job. An exception will be generated if something is not set up
-- properly. 

  DBMS_DATAPUMP.START_JOB(h1);

-- The export job should now be running. In the following loop, the job
-- is monitored until it completes. In the meantime, progress information is
-- displayed.
 
  percent_done := 0;
  job_state := 'UNDEFINED';
  while (job_state != 'COMPLETED') and (job_state != 'STOPPED') loop
    dbms_datapump.get_status(h1,
           dbms_datapump.ku$_status_job_error +
           dbms_datapump.ku$_status_job_status +
           dbms_datapump.ku$_status_wip,-1,job_state,sts);
    js := sts.job_status;

-- If the percentage done changed, display the new value.

    if js.percent_done != percent_done
    then
      dbms_output.put_line('*** Job percent done = ' ||
                           to_char(js.percent_done));
      percent_done := js.percent_done;
    end if;

-- If any work-in-progress (WIP) or error messages were received for the job,
-- display them.

   if (bitand(sts.mask,dbms_datapump.ku$_status_wip) != 0)
    then
      le := sts.wip;
    else
      if (bitand(sts.mask,dbms_datapump.ku$_status_job_error) != 0)
      then
        le := sts.error;
      else
        le := null;
      end if;
    end if;
    if le is not null
    then
      ind := le.FIRST;
      while ind is not null loop
        dbms_output.put_line(le(ind).LogText);
        ind := le.NEXT(ind);
      end loop;
    end if;
  end loop;

-- Indicate that the job finished and detach from it.

  dbms_output.put_line('Job has completed');
  dbms_output.put_line('Final job state = ' || job_state);
  dbms_datapump.detach(h1);
END;

Sign into the Oracle SQL utility of your choice as the database administrator. Run the expdp_export.sql script .

The export (.dmp) file created by this process will be referred to as the database export in this document.

Creating the Export Parameter File for the Oracle Export Utility

After you have set the NLS_LANG environment variable appropriately based on your instance’s current character set, create an export parameter file similar to the following example, substituting the appropriate user name/password of the database administrator and the location and name of the export file to be created.

You can use any text editor to create this parameter file, which will be referred to as parfile in this document.

userid=ownerid/password
buffer=100000
file=outputfile.dmp
rows=Y
indexes=Y
log=logfile.txt
compress=Y
owner=ownerid

Note. Ensure that the file system on which you will be creating the export file has sufficient space available to accommodate all the data in the PeopleSoft database. A good estimate of the space needed is to calculate the amount of space currently taken by tables owned by the PeopleSoft owner ID and adding 20 percent. You can get this data from querying the DBA_FREE_SPACE and DBA_DATA_FILES catalog views. Remember that index data is not stored in export files, only the index definition. If you have insufficient space on any one file system to store the export file, you can use the filesize parameter of the Oracle Export utility. See your Oracle utilities guide for more information on multi-file exports.

Exporting Database Contents Using the Oracle Export Utility

After you create the export parameter file as described in the previous section, call the Oracle Export utility using the following command, substituting parfile with the name of the export parameter file.

exp parfile=parfile

The export (.dmp) file created by this process will be referred to as the database export in this document.

Click to jump to top of pageClick to jump to parent topicCreating a New Oracle Database Instance

This section provides an overview of creating a new Oracle database instance and discusses how to:

Understanding Creating a New Oracle Database Instance

To summarize, the following SQL scripts are run in the following order to create the new database instance:

  1. CREATEDB10.SQL

  2. UTLSPACE.SQL

  3. DBOWNER.SQL (the table to be manually populated as explained in the following sections)

  4. xxDDL.SQL

  5. PSROLES.SQL

  6. PSADMIN.SQL

  7. CONNECT.SQL

The scripts are located in the PS_HOME/scripts directory. More information on these scripts can be found in the installation guide.

See PeopleTools 8.51 Installation for Oracle.

Creating the New Oracle Database Instance

First, you must create a new Oracle instance with a Unicode encoding. This database will become the new PeopleSoft Unicode database.

This database must contain the same tablespaces as the original database, if one or more objects owned by the PeopleSoft owner ID were in those tablespaces.

For example, if the original database had 10 tablespaces, and PeopleSoft used five, you must create those five tablespaces with the same names (but not necessarily the same file paths) in the new Unicode instance.

Important! The AL32UTF8 character set is the preferred Unicode character set for the Oracle database.

When you create the new Oracle instance, be sure to specify CHARACTER SET AL32UTF8 (or CHARACTER SET UTF8) at the end of the CREATE DATABASE command. See the Oracle SQL Reference guide for syntax information on the CREATE DATABASE SQL command.

Pre-Creating Objects in the New Oracle Database Instance

You must pre-create the following objects in the new Oracle database instance:

You must set the NLS_LENGTH_SEMANTICS=CHAR variable at the appropriate point in the database creation process. The installation guide provides information on the use of these scripts and on setting this and other variables.

See PeopleTools 8.51 Installation for Oracle.

Click to jump to top of pageClick to jump to parent topicPre-Creating the PeopleSoft Table Structures Using PeopleSoft Data Mover

Sign on to the newly created Oracle database with PeopleSoft Data Mover in bootstrap mode using the database administrator ID and password.

Once signed in, execute the following Data Mover script, substituting output_file with the name of the structural export file you created in PeopleSoft Data Mover previously: 

SET NO TRACE;
SET NO DATA;
SET INPUT ​output_file;
SET LOG ​log_file;
SET UNICODE ON;
SET STATISTICS OFF;
SET NO INDEX;
SET ENABLED_DATATYPE 9.0;
IMPORT *;

This script creates all the tables in the original PeopleSoft database in the new database with no rows of data and without indexes. Indexes are omitted in this step, since it much more efficient to create indexes after loading table data as compared to loading data into pre-indexed tables.

Note. The ENABLED_DATATYPE 9.0 command applies only if the PeopleSoft application version is 9.0 or higher. With this flag set, the VARCHAR2 columns will use character semantics instead of byte semantics, resulting in better PeopleTools and PeopleSoft application performance.

Click to jump to top of pageClick to jump to parent topicImporting Database Contents

This section provides an overview of importing database contents and discusses how to:

Understanding Importing Database Contents Using the Oracle Data Pump Utility

Once the PeopleSoft tables have been pre-created by PeopleSoft Data Mover, you are ready to import the database export you created.

Important! Ensure that you follow only the instructions for the pair of utilities that you have chosen to use.

Clearing the NLS_LANG Variable

Before running the Oracle import process, clear the NLS_LANG environment variable (Unix) or remove the NLS_LANG registry setting (Microsoft Windows). Doing so ensures that the Oracle import process reads the character set information from the export file and performs the appropriate conversion to the database’s selected Unicode character set.

Importing Database Contents Using Oracle Data Pump

Create an import script to run Oracle Data Pump. You can use any text editor to create an export script similar to the following, which will be referred to as impdp_import.sql in this document. Enter the following commands in impdp_import.sql:

DECLARE
  ind NUMBER;              -- Loop index
  h1 NUMBER;               -- Data Pump job handle
  percent_done NUMBER;     -- Percentage of job complete
  job_state VARCHAR2(30);  -- To keep track of job state
  le ku$_LogEntry;         -- For WIP and error messages
  js ku$_JobStatus;        -- The job status from get_status
  jd ku$_JobDesc;          -- The job description from get_status
  sts ku$_Status;          -- The status object returned by get_status
BEGIN

-- Create a (user-named) Data Pump job to do a "full" import (everything
-- in the dump file without filtering).

  h1 := DBMS_DATAPUMP.OPEN('IMPORT','FULL',NULL,'EXPATOU', 'LATEST');

-- Specify the single dump file for the job (using the handle just returned)
-- and directory object, which must already be defined and accessible
-- to the user running this procedure. This is the dump file created by
-- the export operation in the first example.

  DBMS_DATAPUMP.ADD_FILE(h1,'dataPumpDBExport.dmp','DMPDIR');

-- A metadata remap will map all schema objects from HR to BLAKE.

-- ***  DBMS_DATAPUMP.METADATA_REMAP(h1,'REMAP_SCHEMA','HR','BLAKE');

-- If a table already exists in the destination schema, skip it (leave
-- the preexisting table alone). This is the default, but it does not hurt
-- to specify it explicitly.

  DBMS_DATAPUMP.SET_PARAMETER(h1,'TABLE_EXISTS_ACTION','REPLACE');

-- Start the job. An exception is returned if something is not set up properly.

  DBMS_DATAPUMP.START_JOB(h1);

-- The import job should now be running. In the following loop, the job is 
-- monitored until it completes. In the meantime, progress information is 
-- displayed. Note: this is identical to the export example.
 
 percent_done := 0;
  job_state := 'UNDEFINED';
  while (job_state != 'COMPLETED') and (job_state != 'STOPPED') loop
    dbms_datapump.get_status(h1,
           dbms_datapump.ku$_status_job_error +
           dbms_datapump.ku$_status_job_status +
           dbms_datapump.ku$_status_wip,-1,job_state,sts);
    js := sts.job_status;

-- If the percentage done changed, display the new value.

     if js.percent_done != percent_done
    then
      dbms_output.put_line('*** Job percent done = ' ||
                           to_char(js.percent_done));
      percent_done := js.percent_done;
    end if;

-- If any work-in-progress (WIP) or Error messages were received for the job,
-- display them.

       if (bitand(sts.mask,dbms_datapump.ku$_status_wip) != 0)
    then
      le := sts.wip;
    else
      if (bitand(sts.mask,dbms_datapump.ku$_status_job_error) != 0)
      then
        le := sts.error;
      else
        le := null;
      end if;
    end if;
    if le is not null
    then
      ind := le.FIRST;
      while ind is not null loop
        dbms_output.put_line(le(ind).LogText);
        ind := le.NEXT(ind);
      end loop;
    end if;
  end loop;

-- Indicate that the job finished and gracefully detach from it. 

  dbms_output.put_line('Job has completed');
  dbms_output.put_line('Final job state = ' || job_state);
  dbms_datapump.detach(h1);
END;

Sign into the Oracle SQL utility of your choice as the database administrator. Run the expdp_export.sql script.

Ensure that the import completes successfully with no errors before continuing.

Creating an Import Parameter File for the Oracle Import Utility

Create an import parameter file, similar to the export parameter file you created during the export step. This file should have the following commands:

userid=ownerid/password
buffer=100000
file=database_export_file.dmp
rows=Y
indexes=Y
log=logfile.txt 
ignore=Y
full=Y

Running the Oracle Import Utility

Run the Oracle Import utility from the command line using the following command, substituting in the name of the file containing the above parameters.

imp parfile=parfile

Ensure that the import completes successfully with no errors before continuing.

Rebuilding PeopleSoft Temporary Tables

After you import the database, you must rebuild the temporary tables. To rebuild the temporary tables, sign into PeopleSoft Data Mover in non-bootstrap mode. Run the following command: 

CREATE_TEMP_TABLE *

Click to jump to top of pageClick to jump to parent topicSpecifying the Unicode Database and Data Types in Your PeopleSoft System

When the import has completed successfully, you must specify in your PeopleSoft system that the database is now a Unicode database. To do this, sign into the Oracle SQL utility of your choice using the database owner ID. Run the following SQL statement:

UPDATE PSSTATUS SET UNICODE_ENABLED=1;

Since you set ENABLED_DATATYPE previously, you also need to specify that the database uses Oracle CLOB and BLOB fields, as follows: 

UPDATE PSSTATUS SET DATABASE_OPTIONS=2;

Click to jump to top of pageClick to jump to parent topicRunning GRANT.SQL

Before signing into the new PeopleSoft Unicode database, edit the GRANT.SQLscript (provided in your PeopleTools installation in the scripts directory) to include the connect ID you created previously. Then, run GRANT.SQL to set up the appropriate grants to the connect ID.

Sign into the Oracle SQL utility of your choice using the database administrator ID and password. Run the GRANT.SQL script.

You should now be able to log into your new PeopleSoft Unicode database using Application Designer.

Click to jump to top of pageClick to jump to parent topicRerunning an Oracle Database Import

When the PSSTATUS table is imported from a non-Unicode export file, the UNICODE_ENABLED flag is 0.

Therefore, before re-running any PeopleSoft Data Mover imports, or any time PSSTATUS is re-imported from a non-Unicode export file, set the UNICODE_ENABLED flag to 1 and set the DATABASE_OPTIONS to 2.

Click to jump to parent topicConverting to Unicode on Microsoft SQL Server and DB2/UDB Databases

This section discusses how to:

Click to jump to top of pageClick to jump to parent topicUnderstanding Converting to Unicode on Microsoft SQL Server and DB2/UDB Databases

On Microsoft SQL Server and DB2/UDB databases, PeopleSoft supports converting a PeopleSoft 8.x database to Unicode by re-creating the database using Data Mover to import database contents. For the best performance, run Data Mover on the same machine as the database server.

PeopleSoft requires that an entire database be created as a Unicode database or as a non-Unicode database – mixing CHAR and NCHAR columns in a single PeopleSoft database is not supported.

Click to jump to top of pageClick to jump to parent topicExporting PeopleSoft Databases Using PeopleSoft Data Mover

Sign into the PeopleSoft 8.x database using PeopleSoft Data Mover in non-bootstrap mode, and run the following script. 

SET NO TRACE;
SET OUTPUT ​outputfile; 
EXPORT *;

The DAT file created by PeopleSoft Data Mover will contain all the data in the PeopleSoft database, so be sure that the volume to which it will be written has sufficient disk space to handle and store the exported data.

This process will create a file containing the structure and contents of your PeopleSoft database.

Click to jump to top of pageClick to jump to parent topicCreating New SQL Server or DB2/UDB PTSYS Unicode Databases

You will need to create a new SQL Server or DB2/UDB PTSYS database corresponding to your target PeopleSoft 8.x Unicode database. On SQL Server this database can co-exist on the same server as your original non-Unicode database, as SQL Server allows Unicode and non-Unicode databases to reside on a single server, regardless of the character set selected during SQL Server installation.

To create this database, follow the steps in the appendix “Creating a Database Manually” in the PeopleTools installation guide, from the beginning of the appendix. Stop at the step titled “Creating Data Mover Import Scripts” and continue with the steps below. You can also create a new database using the Database Configuration Wizard, but do not allow the wizard to start importing data.

See PeopleTools 8.51 Installation for Microsoft SQL Server, “Creating a Database Manually.”

See PeopleTools 8.51 Installation for DB2 UDB for Linux, UNIX, and Windows, “Creating a Database Manually.”

Click to jump to top of pageClick to jump to parent topicImporting Database Contents Using PeopleSoft Data Mover

Run PeopleSoft Data Mover in bootstrap mode against the new database. Login in bootstrap mode using the OwnerID and password. Once signed in, run the following script:

SET NO TRACE;
SET INPUT ​inputfile;
SET UNICODE ON;
IMPORT *;

This will import the entire contents of your original database into the new database, while creating character columns using the NCHAR data type (for SQL Server) or VARBINARY data type (for DB2), and converting your data to Unicode.

Click to jump to top of pageClick to jump to parent topicSpecifying Unicode Databases in PeopleSoft Systems

Once the database has finished importing, run the following SQL statement either through PeopleSoft Data Mover, PeopleSoft Query Analyzer (ISQLW.EXE), or db2connect.

UPDATE PSSTATUS SET UNICODE_ENABLED=1

This sets a flag that specifies to PeopleSoft that it is operating against a Unicode database.

Click to jump to top of pageClick to jump to parent topicRerunning GRANT.SQL

Before signing onto Application Designer to create your views, you must first re-run GRANT.SQL (provided in your PeopleTools installation in the SCRIPTS directory) to grant access to the newly created tables to your connect ID. Once this is completed, you should be able to sign into Application Designer.

Click to jump to top of pageClick to jump to parent topicRerunning Microsoft SQL Server and DB2/UDB Database Imports

When the PSSTATUS table is imported from a non-Unicode export file, the UNICODE_ENABLED flag is set to 0. Before re-running any PeopleSoft Data Mover imports, or any time PSSTATUS is re-imported for a non-Unicode export file, set the UNICODE_ENABLED flag to 1.