OBIEE Blog

I was just about to file an SR – and quick search shows that someone else has already had this problem.

OBIEE 10.1.3.4 is Not Supporting Excel 2007 – File you are Trying to Open is in a Different Format than Specified by the File Extension – Contain Features not Compatible [ID 980627.1]

Comments
——–
OBI APPS 7.8.2.13 [19250]
OBIEE 10.1.3.4
Microsoft Windows x64 (64-bit)

- Oracle OBIEE 10.1.3.4 is not supporting MS Office 2007.

- We are trying to download a report from answers to Excel 2007 but its downloading as Excel 2003.
- Why is it?

- After clicking Download -> Download to Excel, in the request, saving the file and then trying to open it in 2003, the following message appears:

”
Microsoft Office Excel

The file you are trying to open, ‘Test.xls’, is in a different format than specified by the file extension. Verify that the file is not corrupted and is from a trusted source before opening the file. Do you want to open the file now?
[Yes][No][Help]
”

If I click on Yes button, I am able to open the report.

If I update some values and try to save then I get a warning message:

”
Microsoft Office Excel

test.xls may contain features that are not compatible with Single File Web Page. Do you want to keep the workbook in this format?

- To keep this format, which leaves out any incompatible features, click Yes.
- To preserve the features, click No. Then save a copy in the latest Excel format.
- To see what might be lost, click Help.

[Yes][No][Help]
”

I have to click on Yes button then it can be saved.

I should update and save this 2003 excel type on excel 2007 without any warning message.

- In Citrix, If I use Download -> Download to Excel and click on open button to open the file, I get this popup:

”
Windows Installer

Preparing to install…

[Cancel]
”

and that ends up with error:

”
D:\TEMP\…\Temporary_Internet_Files\Content.IE5\STMP6X8Z\Test.xls

Only Administrators have permission to add, remove, or configure server software during a Terminal services remote session. If you want to install or configure software on the server, contact your Network Administrator.

[Ok]
”

Solution

Comments
——–
1. Excel 2003 documents can be opened in Excel 2007.

2. From Release Notes OBIEE 10.1.3.4.1:
(“http://download.oracle.com/docs/cd/E10415_01/doc/bi.1013/e10404/toc.htm)
”
4.1.18 Limitation on the Number of Rows in MS Excel 2007
This issue applies to Versions 10.1.3.3, 10.1.3.3.1, 10.1.3.3.2, and 10.1.3.3.3. It is fixed in version 10.1.3.4.

In Microsoft Excel 2007, users cannot insert views that have more than 65536 rows. This is because Oracle BI Office uses an Excel 2003 based template, which has a limit of 65536 rows per sheet.
”

So, template used is for Microsoft Windows Excel 2003.

3. There is an Enhancement Request already filed asking to use an Excel 2007 template.
It is Document Bug 6970162, “Abstract: DOWNLOAD TO EXCEL REQUIRES TRANSLATION WHEN OFFICE 2007 INSTALLED”.

It is set to be reviewed for future versions. It has not yet been approved to be included in a particular version.

4. About the error you get when you try to open the downloaded file, in Excel 2007:

”
Microsoft Office Excel

The file you are trying to open, ‘Test.xls’, is in a different format than specified by the file extension. Verify that the file is not corrupted and is from a trusted source before opening the file. Do you want to open the file now?
[Yes][No][Help]
”

It is an Excel 2007 issue.

ORACLE cannot  be responsible for giving you solutions for Microsoft Excel Issues, as it is not our area.
You could google the error.
Nevertheless, we are giving you an example of one of the documents available in Google for that error. Please, be aware it is being given as a guideline, if you want to try it.

There is a descdription and some workarounds provided at:

http://www.itexperience.net/2008/03/17/excel-2007-error-different-format-than-specified-by-the-file-extension/

where they say:
”
This errors particularly occurs when you’re trying to open an XLS file (Excel 2000-2003) with Excel 2007. In most cases, the problem can be solved by defining MIME types and associating them with extensions.
When you’re using a Document Management System (like Sharepoint or Livelink), you can try adding these:
.xls = application/msexcel
.xlsx = application/vnd.openxmlformats-officedocument.spreadsheetml.sheet

However, if you don’t want to look for a solution, but just want to solve the problem, insert this key in your registry to suppress the notification:

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Excel\Security]
“ExtensionHardening”=dword:00000000

You can accomplish the above by doing the following:

Open your Registry (Start -> Run -> regedit.exe)
Navigate to HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\OFFICE\12.0\EXCEL\SECURITY
Right click in the right window and choose New -> DWORD
Type “ExtensionHardening” as the name (without the quotes)
Verify that the data has the value “0?
”

You could talk to your Microsoft Excel Support to verify the workarounds given above, or to provide another solution.

5. About the error you get once you modify the file in Excel 2007 and try to save it:

”
Microsoft Office Excel

test.xls may contain features that are not compatible with Single File Web Page. Do you want to keep the workbook in this format?

- To keep this format, which leaves out any incompatible features, click Yes.
- To preserve the features, click No. Then save a copy in the latest Excel format.
- To see what might be lost, click Help.

[Yes][No][Help]
”

It seems to be due to OBIEE using mhtml when exporting to Excel.

There is an Enhancement Request already filed, Document Bug 5661454, “ABILITY TO GET EXCEL VIEWER WORKING WITH ‘DOWNLOAD TO EXCEL’”, requiring changing Excel download from MHTML to native Excel format.
It has been approved to be included in OBIEE 11.1.1.2.0.

Document Note 749436.1, “Download to Excel from reports downloading as HTML/MHTML rather than ‘real’ Excel”, explains more about that.

Having said that, the following document provides some information on the error when trying to save files with some formats in Excel 2007 (again, it is not an ORACLE article, so we are giving it only as a guide):

http://office.microsoft.com/en-us/help/hp100141051033.aspx

They say:
”
The Microsoft Office Excel 2007 Workbook format (.xlsx) preserves all worksheet and chart data, formatting, and other features available in Office Excel 2007, and the Macro-Enabled Workbook format (.xlsm) preserves macros and macro sheets in addition to those features.

If you frequently share workbook data with people who use an earlier version of Excel, you can work in Compatibility Mode to prevent the loss of data and fidelity when the workbook is opened in the earlier version of Excel, or you can use converters that help you transition the data. For more information, see Use Office Excel 2007 with earlier versions of Excel(http://office.microsoft.com/en-us/help/HA100775611033.aspx).
…
…
…
Web Page and Single File Web Page
These Web Page file formats (.htm, .html), Single File Web Page file formats (.mht, .mhtml) can be used for exporting Excel data. In Office Excel 2007, worksheet features (such as formulas, charts, PivotTables, and Visual Basic for Application (VBA) projects) are no longer supported in these file formats, and they will be lost when you open a file in this file format again in Excel.
”

6. About the other errors you get on Citrix:

”
Windows Installer

Preparing to install…

[Cancel]
”

and

”
D:\TEMP\…\Temporary_Internet_Files\Content.IE5\STMP6X8Z\Test.xls

Only Administrators have permission to add, remove, or configure server software during a Terminal services remote session. If you want to install or configure software on the server, contact your Network Administrator.

[Ok]
”

You would need to verify them with your Citrix Support, as they cannot be reproduced outside Citrix. The error text seems to say you do not have permissions to write in the TEMP directory for IE to create a temporary Excel file. It is a Windows issue also, apparently.

References
BUG:5661454 – ABILITY TO GET EXCEL VIEWER WORKING WITH ‘DOWNLOAD TO EXCEL’
BUG:6970162 – DOWNLOAD TO EXCEL REQUIRES TRANSLATION WHEN OFFICE 2007 INSTALLED
NOTE:749436.1 – Download to Excel from reports downloading as HTML/MHTML rather than ‘real’ Excel

If you had problems using EVALUATE function -  please look at the following SR that I just found. Apparently, the work-around is to use CAST function.

QL Request: SET VARIABLE QUERY_SRC_CD=’Report’,SAW_SRC_PATH=’/users/administrator/last_working_day test 1′;SELECT “Task Type”.Type saw_0, “Task – Creation Date”.Date saw_1, EVALUATE(‘num_of_working_days(%1,%2)’,”Task – Creation Date”.Date,”Task – Last Updated Date”.Date) saw_2, “Task – Last Updated Date”.Date saw_3 FROM “SPS – Operation” ORDER BY saw_0, saw_1, saw_2, saw_3

The query fails and the following error occurs.

ERROR
———————–
Query Status: Query Failed: [nQSError: 46035] Datatype(DOUBLE PRECISION) nullable(1) unicode(1) external char(0) conversion to datatype(TIMESTAMP) nullable(1) unicode(0) external char(0) is not supported.

These columns are from W_DAY_D. These are type date which the function is expecting. The function returns a number.

BUSINESS IMPACT
———————–
The issue has the following business impact:
Due to this issue, this is holding up resolution of a critical issue on the delivery of the project – which plans to go live next Friday (30th October).

Cause

Comments
——–
The cause of this issue is that EVALUATE expects to return data with a data type that is the same as the data
type of the parameter.
This has been raised in : EVALUATE FUNCTION SHOULD RETURN DATA TYPE OF FUNCTION

The Bug explains that when you use this function:

EVALUATE(‘my_function(%1)’, logical_table.ROWID)

It will set the data type of the column to INT because ROWID is also INT. However my_function does not return an INT but a REAL.

============================
The above is what you are experiencing and why you get the error suggesting converting double precision to timestamp is not supported

[nQSError: 46035] Datatype(DOUBLE PRECISION) nullable(1) unicode(1) external char(0) conversion to datatype(TIMESTAMP) nullable(1) unicode(0) external char(0) is not supported.

Proposed Solution

Customer was asked to do an explicit CAST to set the datatype to the datatype of the value that will be returned by my_function.

So something like

CAST(EVALUATE(‘my_function(%1)’, logical_table.ROWID) AS FLOAT)

The above resolved the issue.

If you’re running OBIEE under 64-bit Solaris – this might be of use. I just want to add from myself – that it’s not a good idea to change repository in online mode.

Admintool Check-in changes: Internal Assertion Error Condition FALSE , file server/Utility/Generci/NQThreads/SUGThread.cpp, line 515 [ID 820803.1]

When checking in changes in Admintool, you are getting the error:

nQSError:28019 Near line 230: In the metadata expression … the following error occured nQSError 46036 Internal Assertion Error Condition FALSE , file server/Utility/Generci/NQThreads/SUGThread.cpp, line 515
Cause

This is a defect:
Bug 6652490: PSR:FUNC:ESSBASE: OBSERVED THE ERROR WHILE CHECK-IN OR SAVING RPD IN ONLINE MODE ?

Bug was logged for 10.1.3.3.2 with OBI server on Solaris 64 bits

Although the abstract mentions Essbase the bug is reproducible against any database.
But only when OBI is on 64 bits solaris platform.
It applies to all versions from OBI 10.1.3.3.1 and later.

Test case:
From Admin tool created the new rpd (i.e. physical layer) and Drag-Drop
the db to Business model & Presentation layer then tried to Check In / Save
form Admin tool in Online mode but I observed the below error form Admin tool
window as well as NQServer.log
Error Message:
[46036] Internal Assertion: Condition FALSE, file server/Utility/Generic/NQ
Threads/SUGThread.cpp, line 515.
2007-11-27 04:44:12
[46036] Internal Assertion: Condition FALSE, file
server/Utility/Generic/NQ
Threads/SUGThread.cpp, line 515

Off line mode able to check-in or saved sucessfully.

Also we only had the error on a Business Model that had been dragged and dropped from the physical.
Solution
The workaround is to modify the NQSConfig.INI file.
Change the “SERVER_THREAD_STACK_SIZE = 0;”
with “SERVER_THREAD_STACK_SIZE = 512 KB;”

and restart the OBI server

Increasing thread stack size (by setting SERVER_THREAD_STACK_SIZE to a bigger number) is the solution to this issue in all versions including 10.1.3.4.

Increasing thread stack size requires more memory from the server machine.
That is the only impact it should have. But increasing from 256k (default) to 512k is a minor change

This defect will be fixed in the next main release

A. “Ago function returning wrong results in answer when comparing this year versus last year” This actually happened to me once – and i thought it was an incorrectly configured time dimension. You can experience this error when your “Time Series functions gives incorrect results when leap years are involved”. Oracle support suggested the following action plan :

1) Leave the logical column definition as earlier i.e. Ago(Measure, Year, 1)
2) Change the filter condition in the request to filter on year and months instead of date range e.g.
year = 2009 and month in (1,2,3,4)

B. “Value Suppression doesn’t work for Level Based Measures”. Someone had a requirement where they wanted to use level-based measures for reports accessing several fact tables in the future. To realize a prototype before starting with the necessary reports they tried to implement an easy example to test the ‘value suppression’ functionality

Unfortunately they are not able to build a nice looking report with four simple columns showing the year, # of orders (per year), quarter and # orders. Their problem is that the level based measure ‘# of order (per year)’ is shown line by line. They wanted to suppress these values and only show the value once per year. They tried to use the ‘value suppression functionality’ without success. They were able to Work around this issues by using a Pivot Table.

C. This issue in pivot table is very common –

OBIEE says “governor exceeded error”. The pivot tables and the charts might give these errors:

Error Generating Chart
An exception occurred in the cube.
Error Details
Error Codes: MOJ5XVNL:QBVC92JY
Governor limit exceeded in cube generation (Maximum data records exceeded.)

and for pivot table

View Display Error
Governor limit exceeded in cube generation (Maximum data records exceeded.)
Error Details
Error Codes: QBVC92JY

Theses messages mean that users are trying to return more rows to the pivot table then the governor will allow. One needs to adjust the following parameters until the report runs successfully.

Adjust the parameters below in instanceconfig.xml (add those tags if you don’t have them – since those values are by default) and then restart Presentation Server (sawserver)

< CubeMaxRecords >40000< /CubeMaxRecords >
< CubeMaxPopulatedCells >150000< /CubeMaxPopulatedCells >

I found an answer to something that bothered me for a while.

In setting up a Time dimension, there are requirement of the physical Tables that can be used, for e.g. Time Dimension table cannot join any physical table other than the fact table Time Dimension sources on the physical layer cannot be part of a complex join In the BM layer any logical Dimension defined as a Time Dimension cannot be part of any other logical tables . In the current 7.9.5 rpd the Date Dimension does not meet some of these requirements So if we were to designate the out of the box OBIApps rpd Date dimension as time dimension we can not have complex join to w_day_d in the physical layer. Currently out of the box OBIApps rpd has several complex join defined with the w_day_d_common alias table which is the detailed level LTC in the Date logical dimension. This issue causes error if you then try to check the time dimension flag and do a consistency check.

A comment on this from one of our Consultant as below “apps 7.9.5 was not ready to convert it to a true time dim. If you check the checkbox you will see all of the consistency errors. Part of it is due to the date fields being used in the inner joins of LTSs on other Dims and Facts which is a no-no for the Time Dim. It is easier just to create your own Time Dim that is used for the Time Series formulas. Or you could configure time series the old school way.” However the OBI 7.9.6 apps does have the Date Dimension checked as a Time Hierarchy. Also an additional response from Engineering as below

==================== The simple answer was that we didn’t use the OBIEE Time Series functions in BI Apps 7.9.5, and used them in BI Apps 7.9.6, hence configuring the Date dimension as a time dimension. In BI Apps 7.9.5, none of the new OBIEE Time Series functions were used. This was because the functionality was immature and had many bugs. These bugs were fixed in OBIEE 10.1.3.4.1 and BI Apps 7.9.6 has uptaken and used the new Time Series functions quite a bit. So for correct functionality of BI Apps 7.9.6, OBIEE 10.1.3.4.1 is a must.

This is interesting. My favorite part is “In BI Apps 7.9.5, none of the new OBIEE Time Series functions were used. This was because the functionality was immature and had many bugs. These bugs were fixed in OBIEE 10.1.3.4.1″ – soif you’re on 10.1.3.2. – you should upgrade as soon as possible (although this might mean months). I knew time dim was broken for a while – it’s just an official confirmation.