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.
If a user is reporting X marks in their browsers when running visual or charting components, the following could be wrong:
If your users encounter an error in a PMF Dashboard that results in an HTTP 404 error, it can be resolved by adding the following to the Tomcat server.xml configuration file:
<Connector connectionTimeout="20000" port="8080" protocol="HTTP/1.1" redirectPort="8443" relaxedQueryChars="^">
file type: SVG
mine string: image/svg+xml
file type: WSP
mine string: text/html
To prevent this issue from happening, make sure that all components deployed with PMF are coming from the secure (HTTPS) alias for your web server farm, and that the user is always accessing it using the same root URL. This avoids cross-site scripting errors.
The redundancy in approot settings is normal since WebFOCUS tends to be installed across multiple physical machines and web servers in your WebFOCUS environment. Regardless of how WebFOCUS is configured, the same version of PMF must be installed to all physical WebFOCUS approot locations. If these locations are configured to different physical disks, you can either cause a conflict between multiple installed versions of PMF or the PMF app might not be installed on one of the disks involved.
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:
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.
While running the sqlora.sql script you may receive an error that tables cannot 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.
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
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
Note: Neither of these queries will detect missing synonyms. For more information on this, please see your Oracle RDBMS documentation.
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.
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).
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 your 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.
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:
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.
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.
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.