Common PMF Errors

In this section:

This topic describes common PMF errors and error messages that point to issues with your PMF configuration and installation. Common remedies for these issues are also recommended.


Top of page

x
The Users See an X Mark Where a Graphic Is Expected

If a user is reporting X marks in their browsers when running visual or charting components, the following could be wrong:


Top of page

x
Strategy Map, Tolerance Sliders, or Menu Buttons Do Not Display

If SVG components such as the Strategy Map, Tolerance Sliders, and the Menu buttons in the Author, Strategy, and Manage tab trees do not display, and you receive a JavaScript error, the following could be wrong:


Top of page

x
JavaScript Errors When Running the Today Page

If users get a JavaScript error when first running the PMF Today page, the following could be wrong:


Top of page

x
Receive an Error With Oracle

When running PMF with a data mart stored on Oracle, you may receive the following error:

(FOC295) A VALUE IS MISSING FOR &TIME_LEVEL01_ABBR

Typically this happens because Oracle is configured for UTF-8 operation. Until version 5.2.3, PMF does not support operating with a UTF-8 data mart. Please reconfigure the data mart for PMF to use a single-byte or double-byte code page. For more information on how to do this, please refer to your Oracle RDBMS documentation.

If this is not possible and you are running on Unix, you can edit the WebFOCUS Server profile (edasprof.prf) and export a single-byte or double-byte NLS_LANG parameter. For example:

export NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252

This will insure that only standard characters are entered into the PMF database.

This error signifies that the file a_defaults.fex in /apps/pmfdata has been corrupted. To restore this, you need to copy file a_defaults_do_not_edit.fex to a_defaults.fex. Then, log off and log back into PMF with an administrator ID and run the Resynch when prompted.


Top of page

x
Errors While Creating an Oracle Database

While running the sqlora.sql script you may receive an error that tables can not be deleted, or rows are not being properly inserted. A likely cause for this error is that you may have specified the PMF owner ID in lowercase. To verify that this is the issue, look at the sqlora.sql file that you are running. If, for example, you see the following:

define PMF_DB_OWNER  ='my_pmf_id'

You need to change the owner ID in the code to uppercase, as seen in the following example.

define PMF_DB_OWNER  ='MY_PMF_ID'

Once the change has been made, run the script again.

Note: You may need to clear your database of any objects that were created with the owner ID in lowercase.


Top of page

x
Snapshot Restore Fails With Oracle RDBMS

In this section:

This scenario can occur due to improper Oracle public synonyms. PMF creates and uses Oracle public synonyms for all PMF tables, views, and stored procedures. This allows the application a high degree of independence from the underlying physical database. However, it is possible for the connections between Oracle public synonyms and its underlying objects to get out of sync, which can result in public synonyms pointing to incorrect or non-existent objects. This typically happens when proper protocols or procedures are not followed for setting up and/or configuring the PMF Oracle database. The most common manifestation of this will be a failure during a PMF release upgrade or resynch, during a Snapshot Import, or while adding, changing, or deleting Dimensions. If this occurs, you will need to analyze the situation to see what has happened and then take appropriate corrective measures.

To detect incorrect synonyms in the base PMF data structures in PMF release 5.2.2, run the following SQL through the standard SQL*Plus query tool.

select * from DBA_SYNONYMS
where SYNONYM_NAME in
(
-- List of 5.2.2 tables
 'ALERTS'
, 'DIMENSIONS'
, 'DIMENSIONS_SOURCE'
, 'DIMENSIONS_TYPE'
, 'FEEDBACK'
, 'FUNC_ROLES'
, 'FUNC_ROLES_ACCESS'
, 'FUNC_ROLES_OBJECTS'
, 'GADGET_CLASS_PARMS'
, 'GADGET_INSTANCES'
, 'GADGET_INSTANCE_OWNERS'
, 'GADGET_INSTANCE_PARMS'
, 'GADGET_PAGE_BLOCKS'
, 'LAUNCH_PAGES'
, 'MEASURES'
, 'MEASURES_ENTRY'
, 'MEASURES_HISTORY'
, 'OBJECTIVES'
, 'OBJECTIVES_LINKAGES_CR'
, 'OWNERS'
, 'PERSPECTIVES'
, 'PERSPECTIVES_OBJECTIVES_CR'
, 'PM_DIM01_DISPLAY'
, 'PM_DIMS_W_SRC'
, 'PM_DIMS_W_SRC01'
, 'PM_DIMS_W_SRC02'
, 'PM_DIMS_W_SRC03'
, 'PM_DIMS_W_SRC04'
, 'PM_DIMS_W_SRC05'
, 'PM_DIMS_W_SRC06'
, 'PM_GADG_CLSS'
, 'PM_GADG_PG'
, 'PM_GADG_PG_GUIDE'
, 'PM_LAUNCH_PAGES_TYPES'
, 'PM_MEAS_SRC'
, 'PM_MEAS_SRC_BRKPNT_VALS'
, 'PM_MEAS_SRC_DIMNSN_TYP_CR'
, 'PM_MEAS_SRC_FLDS'
, 'PM_MEAS_SRC_LOADFILTS'
, 'PM_MEAS_SRC_LOADFLDMAPS'
, 'PM_MEAS_SRC_LOADPARMS'
, 'PM_MEAS_SRC_OBJ_CR'
, 'PM_MEAS_SRC_TLRNCS_BENCHMARK'
, 'PM_MEAS_SRC_TLRNCS_FORECAST'
, 'PM_MEAS_SRC_TLRNCS_STRETCH'
, 'PM_MEAS_SRC_TLRNCS_TARGET'
, 'PM_OBJECTS'
, 'PM_SCENARIOS'
, 'PM_SCENARIO_PARMS'
, 'PM_SYS_MEASRS_FLDS'
, 'PM_SYS_MEASRS_FLDS_TLRNC_CR'
, 'PM_SYS_TLRNC'
, 'PM_SYS_TLRNC_LVLS'
, 'PM_TASKS'
, 'PROCESSES'
, 'PROCESSES_OBJECTIVES_CR'
, 'PROJECTS'
, 'PROJECTS_MEASURES_SOURCE_CR'
, 'PROJECTS_OBJECTIVES_CR'
, 'ROW_LVL_SEC_FILTERS'
, 'ROW_LVL_SEC_ROLES'
, 'SCHEDULES'
, 'SCORECARDS'
, 'SCORECARD_SECURITY'
, 'STRATEGIES'
, 'SYSTEM_SETTINGS'
, 'THEMES'
, 'THEMES_OBJECTIVES_CR'
, 'TIME'
, 'TIME_RANGES'
, 'UNITS'
, 'UNITS_CONVERSION'
, 'UNITS_CONVERSION_CR'
-- List of 5.2.2 views
, 'DIMENSIONS_SOURCE_FLAT'
, 'DIMENSIONS_W_SOURCE'
, 'DIMENSIONS_W_SOURCE01'
, 'DIMENSIONS_W_SOURCE02'
, 'DIMENSIONS_W_SOURCE03'
, 'DIMENSIONS_W_SOURCE04'
, 'DIMENSIONS_W_SOURCE05'
, 'DIMENSIONS_W_SOURCE06'
, 'PM_STRTGY_OBJ_COMPOUND'
, 'PM_STRTGY_OBJ_SIMPLE'
, 'ROW_LVL_SEC_TREE'
, 'SCHEDULES_ALERTS'
-- List of 5.2.2 stored procedures
, 'PMF_DROP_TABLE'
, 'PMF_DROP_VIEW' 
, 'PMF_SEQUENCE_TRIGGER_CREATE'
, 'PMF_SEQUENCE_TRIGGER_RESET'
)
and TABLE_OWNER <> '&PMF_DB_OWNER_CHECK'
order by SYNONYM_NAME
/
undefine PMF_DB_OWNER_CHECK

where:

&PMF_DB_OWNER_CHECK
Is the name of your schema/owner ID. If this query returns no rows, then all of your base PMF objects have the correct synonyms.

To verify that your dimensions were correctly formed, run the following query:

select * from DBA_SYNONYMS
where
 (	
 SYNONYM_NAME in
 (select trim(upper(DIMENSION_TYPE_NAME)) || '_TREE' from DIMENSIONS_TYPE)
 or SYNONYM_NAME in
 (select trim(upper(DIMENSION_TYPE_NAME)) || '_TREE_ALTT' from
DIMENSIONS_TYPE)
 or SYNONYM_NAME in
 (select trim(upper(DIMENSION_TYPE_NAME)) || '_TREE_ALTW' from
DIMENSIONS_TYPE)
 )
and TABLE_OWNER <> '&PMF_DB_OWNER_CHECK'
order by SYNONYM_NAME
/
undefine PMF_DB_OWNER_CHECK

where:

&PMF_DB_OWNER_CHECK
Is the name of your schema/owner ID. As with the previous query, if this query returns no rows, then your synonyms are correctly formed.

Note: Neither of these queries will detect missing synonyms. For more information on this, please see your Oracle RDBMS documentation.



x
Fixing Stored Procedures

If a stored procedure has an incorrect synonym, first verify that the underlying stored procedure has the correct owner. If so, drop and re-create the public synonym. If the underlying stored procedure has an incorrect owner, you must drop both the synonym and the stored procedure. Then, locate the DDL for the stored procedure in the file sqlora.sql, including the final create of the public synonym, copy the DDL into a separate location, and only run that DDL.



x
Fixing Views

If a view has an incorrect synonym, the correction process is basically the same as for stored procedures. If the underlying view has the correct owner, then drop and recreate the public synonym. Otherwise, locate the proper view DDL in the file sqlora.sql, copy this out, and only run the view DDL (including the final create of the public synonym).



x
Fixing Tables

If a table has an incorrect synonym, you will need to determine if your PMF application has been using the incorrect synonym for data storage. If you are configuring a base PMF database, the recommended approach is to simply clear the database of all objects and rerun the base DDL/SQL script. If the synonym is pointing to a non-existent table, drop and recreate the synonym to point to the correct table. Otherwise, if you have two possible tables, you will need to determine which table has been used by the application. For example, suppose you have two DIMENSIONS tables, ABC.DIMENSIONS and XYZ.DIMENSIONS, and the public synonym is pointing to ABC, but you application schema is XYZ. You must look at the underlying data in each of these two tables and determine which has your correct application data. If the XYZ table has your correct data, drop and recreate the public synonym to point to XYZ. Otherwise, if ABC mistakenly has your application data, transfer your application data from ABC.DIMENSIONS to XYZ.DIMENSIONS.

Note: Exercise caution when doing this since many PMF tables have triggers to generate one up sequence numbers for the key values. If this is the case, as it is with the DIMENSIONS table, you must disable the trigger before transferring over the data from the ABC to the XYZ table.

Once the data transfer is complete, you must re-enable the trigger, delete and recreate the public synonym to point to the XYZ table, and drop the ABC table. Fortunately, this last situation is quite rare.


Top of page

x
Data Looks Incorrect or Is Missing

If you ever run a PMF view or gadget and do not see the expected data, here is a list of potential issues to investigate to confirm that you have taken all of the steps necessary to publish your measure data:


Top of page

x
Microsoft SQL Server Log Files Grow to Huge Size

If you use Microsoft SQL Server as the host for your PMF Data Mart, please note that you must manage Microsoft SQL Server configuration regarding log file growth. This is a known issue when using Microsoft SQL Server.

If the log file growth is unmanaged, it is quite possible that the log file can grow to 50GB in size or more.

Typically you manage this by configuring properties for Log files on your master database in Microsoft SQL Server’s administration management console.

Please consult your Microsoft SQL Server documentation for more information and exact procedures.


Top of page

x
Setup Program Crashes Immediately When Started

This issue normally occurs because the installer is being forced to use the wrong JVM, which results in it crashing. The PMF Setup program is packaged and launches its own jvm to prevent problems, but this problem can still happen if the users PC has a hardcoded jvm in their classpath or in their Windows system path. This typically happens if they have, for example, an old Oracle client installed on their machine.

The error message that opens when this occurs can be seen in the following image.

Java Error Message

To remedy this issue, temporarily remove the hardcoded CLASSPATH and/or JVM execution path from the Windows system environment configuration, then restart the PMF Setup program.


WebFOCUS