B Possible Changes in Oracle BI Enterprise Edition Appearance and Behavior After Upgrade

This appendix describes some of the reasons why an Oracle Business Intelligence 11g system might appear or behave differently to the Oracle Business Intelligence 10g system from which it was upgraded, and contains the following sections:

Typically, the changes described in this appendix result from enhancements, bug fixes and architectural changes in 11g. For information on how to plan for upgrading, and about other possible changes that might arise as a result of upgrading, see Chapter 1, "Planning to Upgrade from Oracle BI 10g to BI 11g."

B.1 Oracle BI Enterprise Edition Content Changes

Table B-1 lists and describes possible changes with Oracle BI EE content after an upgrade from 10g to 11g.

Table B-1 Oracle BI EE Content Changes

Change Description

Aggregate rule for running aggregates must be in Answers Reports after upgrade

If a column formula includes running aggregates (such as, MAVG(), MSUM(), RSUM(), RCOUNT(), RMAX(), RMIN()) and views include sub-totals, grand totals, or other columns in the Excluded columns section, then the data is displayed differently in the results in 11g. This difference occurs because the aggregation rule is not specified for this column. Ensure that you determine the correct aggregation rules for the columns. If you want to see the same values as in 10g, then include the following aggregation rules in the Edit Column Formula dialog:

  • MAVG(), MSUM() = Aggregation Rule: Average

  • RSUM(), RCOUNT() = Aggregation Rule: Max

  • RMAX() = Aggregation Rule: Max

  • RMIN() -> Aggregation Rule: Min

Report-based totals

When using report-based totals in table and pivot table views, you might obtain differences in the data in 10g and 11g when a measure column has an aggregation rule of "Server Complex Aggregate" and in sub-totals and grand totals.

The differences occur because the data for this column for sub-totals was produced, for example, by the aggregate() function in 10g. In 11g, this issue is resolved by using the report_aggregate() function to accurately reflect the Report-based Total (when applicable) setting.

Attribute column in measure section might be repeated in a pivot table

In 10g, if you have an attribute column on the row edge and in the measure section, the column is displayed blank. In 11g, the column shows the exact value of the attribute; therefore you might see repeated values.

Data formatting might change in 11g

In 11g, data formatting in some analyses might be different than the data formatting in 10g. For example, if an analysis for 10g has two decimals, then you might not see those two decimals when the analysis is upgraded to 11g.

In 11g, the system attempts to honor analysis-level or view-level data formats. However, in cases where no data format has been specified, the system relies on the default behavior of the graphing engine. This reliance might create differences in formatting between analyses in 10g and 11g.

Font weight and alignment issues

In 11g, there are changes in font weight and alignment that result from changes in default style sheets and skins.

Grand total is not highlighted with color

The default formatting for grand totals is different in 11g, and this difference might cause missing color highlighting for the grand total row.

Gray cell borders not kept

In 11g, there is a change of borders from bottom/right to top/left for hierarchical columns. You can reset the borders manually using analysis definitions.

Hidden but included data is not displayed

In 10g, if a column is hidden but included in a pivot table, the data is displayed in the pivot table. In 11g, if the column is hidden at the criteria level, then the data is not displayed.

Hidden columns used for labels are not displayed

Hidden columns used for labels in 10g are not displayed in 11g. If you have a column that is used as the label for a graph, but the column is hidden from the graph, then in 11g, the labels are not displayed.

Incorrect formatting while using reserved keywords

In 11g, reserved keywords, for example, CASE, WHEN, SELECT, PERCENT, must be double quoted. Otherwise, you might see incorrect formatting.

Missing view in 11g

In 11g, the query does not run if there are no data views in the analysis. In 10g, the query runs and displays a No Results view if there were no results. This difference might cause a missing view in 11g.

Navigations, drills, or action links might result in additional filters

In 11g, extra filters might be displayed while navigating, drilling, or clicking action links. The value of the item clicked and all the values to the left of the item clicked are passed, including the values for any columns that are set to repeat. This could result in additional filters being applied. However, only the value of the item clicked and values of items to the left are passed in 10g.

No Results message displayed

In 10g, if there is a column selector and the first column in the column selector does not return any results, then the column selector view is displayed, which allows you to select other columns. In 11g, a No Results message is displayed and you cannot see the other columns. See the "Analysis Properties Dialog" topic in Oracle Fusion Middleware User's Guide for Oracle Business Intelligence Enterprise Edition for information on setting the No Results message.

Oracle BI Server returns all month and day names as three-letter abbreviations.

The BI Server returns all month and day names as three lettered abbreviations. To use full names, modify the NQSConfig.ini file to specify YES for the following values:


After this change, any analysis that uses a CASE statement with month names or week names must match the statements to be either long name or short name according to the setting in the NQSConfig.ini file.

Possible data difference with time-series data

In 11g, time-series functions, such as ToDate and Ago, do not automatically add hidden key columns to the analysis as in 10g. This might cause possible data differences in 11g.

Report_count does not support distinct keyword

In 11g, Report_count does not support distinct keywords. Therefore, analyses must use count (distinct) instead of countdistinct. This requirement affects the data when you select to use TopN or BottomN in the filter for a measure.

Integer division returns integer in 11g

Integer division that returns decimal data in 10g returns an integer in 11g. You might notice these return values for a column in the following cases:

  • The results of the analysis lose the decimal points.

  • Data order is slightly different for the column. Because data is sorted without decimal points, some rows might contain the same values.

  • Formatting of the column is changed because the default formatting for integer (if configured) is used. (In 10g, the default format is used for double data types.)

To force integer division to return decimal results, cast the numerator to a double data type before the division. For example:

"int x" / "int y" = "int z"
Cast( "int x" as float) / "int y" = "float z"
Cast( "int x" as double) / "int y" = "double z"

If this is different behavior than you saw in 10g, then it is because a known issue caused integer division to incorrectly produce a decimal result when certain physical data sources where used.

To maintain the same result as 10g, you can create a session variable called DISABLE_FLOOR_IN_DIVISION with a value of 1.

Integer data types now double data types

You can override the default data format for columns that were integer data types in 10g, and are now double data types in 11g. Without this workaround, the data for this column displays as a decimal number with two digits to the right of the decimal point.

You might notice this change for a column in the following cases:

  • The results of the analysis show decimal points where integers were shown in 10g.

  • Formatting of this column is changed because the default formatting for double (if configured) is used in 11g.

You can using the following options to maintain the same result as 10g:

  • Use the Cast function to cast the values to the appropriate data type in the metadata repository.

  • Change the formatting for the column to display only integers and save that specification as the default format.

Return data from certain columns might be different

In some situations, the return data type of certain columns in 11g can be different from 10g. In 10g, some data sources, such as SQL Server and IBM DB2, return an integer for division formulas such as AVG, while other data sources return a double. In 11g, the results of all division formulas are promoted to a double type regardless of the data source, for consistency and for a more correct and precise value.

This difference might impact analysis results because some analyses from previous releases might not be formatted properly for decimal points. If this occurs, then override the default data format for columns that were integer data types in the previous release, but that are now double data types. If you do not perform this step, then the data for affected columns is displayed as a decimal number with two digits to the right of the decimal point.

See the description for the "Integer data types now double data types" change for details on how you might notice this change and on how you can obtain the same results as in 10g.

Possible duplicate navigations

In 11g, action links are generic and upgraded to criteria action links for measures. As a result, there might be duplicate navigations. In addition, a view might be pointing to a non-existent analysis, which results in a "Path Not Found" error.

For example, suppose that you have a 10g report with two hidden graphs, and each has an action link on it. When the report is upgraded, all graph action links are upgraded to criteria action links for measures, which results in additional action links in other views. In this example the action links in the original graph point to non-existent analyses. To work around this situation, manually remove such action links.

In 9.0 environment, you can see the scale appeared between $0 To $100. In 7.x the scale appeared in negative values, for example $0, -$10,000, -$20,000, -$30,000.

Un-check the Use logarithmic scale from Scale in Graph properties dialog and save the report. In some rare cases, 7.x users can select both Use logarithmic scale and Dynamic radio button compared to 9.x users.

B.2 Changes to the NQSConfig.INI Configuration File in Oracle BI Enterprise Edition 11g

The NQSConfig.INI configuration file in Oracle BI Enterprise Edition 11g was changed as described in the following sections:

B.2.1 Additions to the NQSConfig.INI File

The following parameters were added to the NQSConfig.INI file:







  • hadoop













  • OracleCEP_HTTP






  • timesten

  • timesten35



For more information about these parameters, see "NQSConfig.INI File Configuration Settings" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

B.2.2 Removals from the NQSConfig.INI File

In the NQSConfig.INI file, the SSL_VERIFY_PEER parameter has been deprecated and replaced by the SSL_VERIFY_CLIENTS and SSL_VERIFY_SERVERS parameters. For more information, see Section, "Upgrading an Existing SSL Environment."

B.3 Changes to the Scheduler instanceconfig.xml Configuration File in Oracle BI Enterprise Edition 11g

The following parameter was added to the instanceconfig.xml file for Scheduler in Oracle BI Enterprise Edition 11g:

  • UseStartTLS

For more information about this parameter, see "Email Scheduler Configuration Settings that Affect Agents" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.