OBIEE Blog

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

Something else, I’ve found. I suggest always adding 1.00* when working with non-integers, just for sake of convenience.

(Customers.”Total Customers” / sum(Customers.”Total Customers”)) * 100
Cause
The problem was caused because that Integer Data Type values are involved in the calculation. If the calculation is performed on Integer values, then the correct answer is ‘0′.

When a Grand Total is specified, then the Data Type is promoted to Double Precision. If the operation is performed on a Double Precision field, then non-zero values will be returned.

Solution

The solution to this issue and to ensure that non-zero values can always be returned in an OBI EE Report is by modifying the formula expression as follows: -

e.g. (1.0*Customers.”Total Customers” / sum(Customers.”Total Customers”)) * 100 or 1000*Customers.”Total Customers” / sum(Customers.”Total Customers”)

When viewing the properties of a fact column in OBIEE, there is a check box “data is dense” when aggregating by dimension is chosen. What does this check box do? I’m not sure if this only applies to multi-dimensional sources or not.

Solution

This is generally used for FIRST/LAST aggregation rules where data is dense across the time dimension, e.g. inventory values for every period. SQL generation is optimized in this case.

There was a problem in drill down in one of the hierarchy with the order it displays the lowest level attributes.

When drilling down on a certain category – “Organization”, Answers always shows columns in the following order:
Organization Name,Department Name, Sub-Department Category, Org Detail Number, Org Detail Name

The desired order is:
Organization Name,Department Name, Sub-Department Category, Org Detail Name, Org Detail Number

The hierarchy was defined as following in the RPD (please note that Org Detail Name and Org Detail Number are at the same lowest level defined as keys):

Organization Name
Department Name
Sub-Department Category
Org Detail Name | Org Detail Number

It has been found that it doesn’t sort alphabetically.

With Oracle’s OBIEE support and help – the solution has been found:

1. Use the Query Repository feature under Tools menu in the RPd to do a search of these 2 columns in the RPD.
2. In the Query Repository window note down the IDs for these 2 columns. Please check which one is bigger than the other.
3. The logical table, delete the 2 columns (Org Detail Name and Org Detail Number) and add them again in the desired order. Make sure you add them in the correct order. Query for the columns again, the IDs should be in the reverse order as step 2.
4. Add them in the hierarchy again
5. Change the order of level keys in Dimension hierarchy
6. Save the changes and test again.

After RPD re-deployment – it was working.

There must be an easier way to change order of composite key (complex key) columns.