OBIEE Blog

Direct Database Request in OBIEE using Essbase causes [nQSError: 46008] Internal error: File .\Src\SQXDGEssbaseCAPI.cpp, line 1003. (HY000)

Applies to:
Business Intelligence Answers Option – Version: 10.1.3.2.1 to 10.1.3.4.1 [1900] – Release: 10g to 10g

Symptoms

When running a query in Direct Database Request in OBIEE against Essbase, the following error occurs:

ERROR
———————–

State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 43093] An error occurred while processing the EXECUTE PHYSICAL statement. [nQSError: 46008] Internal error: File .\Src\SQXDGEssbaseCAPI.cpp, line 1003. (HY000)

The query works in Answers screen but not in Direct Database Request screen.

STEPS
———————–
By following these steps the issue can be reproduced using Essbase as data source:
1. Create a report in Answers
2. Verify that the query returns results
3. Now copy the physical SQL of the above query from the query log (section ‘…sending query to database…’)
5. Copy it into the Direct Database Request SQL statement field
6. Verify that the columns in SELECT statement are displayed in the Results Column section
7. Run the results and the above error is generated

Cause

This issue has been caused by Bug 6869282 “DIRECT DATABASE REQUEST THROWS ERROR WHEN RUNNING AGAINST ESSBASE”.

There is an issue with the code that checks for FROM clause in the SQL. The parsing code expects a space before and after the FROM clause.

Solution

The behavior is reproducible in the latest version of OBIEE, 10.1.3.4.1.

The recommended workaround is in the MDX  query to enter space before the “FROM” clause in the physical SQL and execute the query.

A single space before the FROM clause resulted in the following error (the error moves from line 1003 in the error described above to contrary to line 1050 in error below):

Odbc driver returned an error (SQLExecDirectW).
Error Details
Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 43093] An error occurred while processing the EXECUTE PHYSICAL statement. [nQSError: 46008] Internal error: File .\Src\SQXDGEssbaseCAPI.cpp, line 1050. (HY000)

Adding two spaces in front of the FROM clause so that the FROM clause is aligned with the text in the upper line of the query, resolved the error and it was possible to run Direct Direct Database requests in OBIEE on Essbase.

Bug 6869282 “DIRECT DATABASE REQUEST THROWS ERROR WHEN RUNNING AGAINST ESSBASE” is planned for resolution in the next release of OBIEE.

There’s an interesting discussion about IIS and OC4J on OTN- OC4J discussion

I think there’s a lot of confusion as to what is a difference between web server and web application server (apparently web server just serves static HTML (it can also server PHP/ASP pages), however, doesn’t run applications — on the other side – it’s tough to distinguish between dynamic web applications written in script languages and Java container OC4J). If you

I think that it’s clear from the discussion that OBIEE requires IIS (in Windows server) and OC4J is an quasi-optional module for BI Publisher and Scheduler.

Another thing -check your connection pool settings. According to Oracle, BI Server might crash if there’re “Several Connection Pools in the custom RPD had ‘Execute Queries Asynchronously’ enabled. This is no longer recommended in OBI 10g as it can cause the OBI EE (NQServer) Server to crash.”

This is addressed in Bug No.BUG 7634602 – ‘OBI SERVER CRASH – 3-818156441′

If you’re unable to configure proxy “Act as” feature maybe this can help you.

The customer had OID/SSO users in lowercase but had the users in the proxy table in upper case.

Also the string (‘VALUEOF(NQ_SESSION.RUNAS)’) was not in uppercase in both the proxyblock and proxylevel init blocks

Initially, on selecting ‘act as’ the following error was reported:
“This functionality has not been correctly configured by your administrator (Can’t retrieve the list of target users).”

The customer had OID/SSO users in lowercase but had the users in the proxy table in upper case. Advised the customer to add upper function to proxy related init block queries and in the XML template file queries as well. This resolved this error message and the customer was able to see the list of target users.

Then on selecting a particular user from the list of target users it failed. It gave the error message : “Not logged in”.

Since the customer had OID/SSO setup, the customer was advised to test with rpd users.

Even with rpd users the functionality still failed to work and reported the following error:
“Access for requested connection is refused. Failed to get the value of PROXY session variable”.

Finally, what seemed to resolved the problem for the customer was changing the string (‘VALUEOF(NQ_SESSION.RUNAS)’) in all uppercase in both the proxyblock and proxylevel init blocks.

Symptoms
After migration from 10.1.3.2.1 to 10.1.3.4 Prompt selection window not rendering correctly when a Multi Select Prompt is created for OBI EE Dashboard Prompts.

In Answers, On clicking to go to the selector screen for the Multi-Select Prompt, in it we see on the right:
match: begins with…. the right side is empty. Also the left side (‘Selected’) is empty.
So, No values display in the list.

Details:
- Customer has tried entering a value in the textbox and clicking go, nothing happens.
- The issue does not happen on customers 10.1.3.2.1 instance. It only happens on their 10.1.3.4 instance which they have migrated from 10.1.3.2.1.
- Web Server is Apache\Tomcat 5.5
- Java version is JDK 1.5.18

Steps to reproduce:

- Log into Answers
- At top of left Answers window select ‘New Dashboard Prompt icon, & select a subject area
- from the list on the left select a dimension (eg Calendar Month Desc)
- change Control to ‘Multi-select’
- select ‘Constrain’
- change Defaults To to ‘Specific Value’
- from that list select a value
- top right of screen select the Preview icon
- next to default value, select the icon to bring up the Multi-select window.
- the issue is seen here, no values in the list.
Cause

Client migrated from 10.1.3.2 to 10.1.3.4. During the migration they replaced the ‘res’ folder with the copy from their 10.1.3.2 version and then regenerated the war file. The same war file was deployed in Tomcat.

This is the root of the problem. The ‘res’ folder should not be copied from the older version instance.
Solution

Obtain a fresh 10.1.3.4 ‘res’ folder and replace the copied 10.1.3.2.1 version with that.

When running a report using eight BETWEEN clauses or less for a report that should bring back zero rows, for example

SELECT Products.Brand saw_0 FROM Paint
WHERE (Products.Brand BETWEEN ‘0′ AND ‘1′)
OR (Products.Brand BETWEEN ‘1′ AND ‘2′)
OR (Products.Brand BETWEEN ‘2′ AND ‘3′)
OR (Products.Brand BETWEEN ‘3′ AND ‘4′)
OR (Products.Brand BETWEEN ‘4′ AND ‘5′)
OR (Products.Brand BETWEEN ‘5′ AND ‘6′)
OR (Products.Brand BETWEEN ‘6′ AND ‘7′)
OR (Products.Brand BETWEEN ‘7′ AND ‘8′)
ORDER BY saw_0

the following warning is displayed:

“…

No Results
The specified criteria didn’t result in any data. This is often caused by applying filters that are too restrictive or that contain incorrect values. Please check your Request Filters and try again. The filters currently being applied are shown below ..”

This is the correct result.

However, when an additional BETWEEN clause is added (i.e nine BETWEEN clauses in total) for example

SELECT Products.Brand saw_0 FROM Paint
WHERE (Products.Brand BETWEEN ‘0′ AND ‘1′)
OR (Products.Brand BETWEEN ‘1′ AND ‘2′)
OR (Products.Brand BETWEEN ‘2′ AND ‘3′)
OR (Products.Brand BETWEEN ‘3′ AND ‘4′)
OR (Products.Brand BETWEEN ‘4′ AND ‘5′)
OR (Products.Brand BETWEEN ‘5′ AND ‘6′)
OR (Products.Brand BETWEEN ‘6′ AND ‘7′)
OR (Products.Brand BETWEEN ‘7′ AND ‘8′)
OR (Products.Brand BETWEEN ‘8′ AND ‘9′)
ORDER BY saw_0

the result should also return zero rows but this report returns all rows in the table.

In the query using nine BETWEEN clauses, the WHERE clause of the SQL generated does not include the BETWEEN filter conditions hence all rows in the table are returned.

It was determined to be a bug – OBI SERVER GENERATES INCORRECT SQL WHEN BETWEEN AND OR CLAUSES EXCEED EIGHT, has been raised to address this sissue.

The issue is that for the case when there are more than 8 filters, e.g 9 filters in a query, OBI Server seems to drop the filter with the result that it erroneously returns incorrect number of rows.