OBIEE Blog

There’re some very interesting blog posts about handling OBIEE’s SCM process, however, the difficulty is that each project is different. For example, there’re so many environmental factors involved – everything depends on location. In some enterprises, they use corporate-wide version-control systems (such as TFS). In some places, they don’t. Some companies have a rigid DEV to SIT to UAT to PROD process, in some companies – such development is done ad-hoc.

Sometimes, webcat is copied manually. Sometimes, it’s merged online. Sometimes it’s archived and extracted.

Myriad options and almost endless number of possibilities.

Sometimes, the RPD is merged locally, sometimes it’s imported, sometimes, it’s done via MUDE projects. Everyone is different and each situation is different. And here’s when experience and expertise come into play – an experienced consultant can provide the best way of handling OBIEE’s deployment process.

I received only 18 responses to the survey so far. I think I’ll wait until tomorrow to publish results. I also realized that some of the questions weren’t worded clearly – hence the confusion.

One of the most notable articles this week – Oracle BI EE 10.1.3.4.1 – Multi Hierarchy reporting article by Venkatakrishnan J where he’s using a very clever fragmentation tactic to control hierarchy and drill-down order. Very out-of-the-box!

John Minkjan has posted several interesting OBIEE findings here.

Check out this newly minted federal IT spending Dashboard – I think it’s a good starting effort, but there’re many problems with its current implementation, such as – site not working correctly in Firefox, using too much Flash (I wonder if it’s 508 compatible), confusing UI, not very detailed). On a positive side – there’re many ways to create customized feeds and export data to CSV. I’m actually wondering which new business opportunities would be created if US Government continues to open more and more federal data to public.

Stay tuned.

Even though I’m hanging on the bottom of Top 10 users, I still managed to make it to Pro Level today Now I have a nice silver icon to my name (or maybe it’s platinum, since the previous one looked like gold). Now, after giving myself pat on the back – let’s continue.

I still think the point system for the forum is mostly benefiting 2 sides – the forum itself  & novices trying to make it to the market and not taking their due diligence to make simple forum or google search / RTFM. It’s encouraging me and fellow experienced colleagues to answer really rudimentary questions (”what is RPD? my AdminTool doesn’t work – oops I didn’t install it; I need to format my report a certain way – how do I change cell background?”   . There’re several major flaws of the point system on any forum – first, a lot of stupid questions and second, it’s bringing competition spirit and making experienced folks answering those.  Does “Pro” status mean anything? I’m not sure -since there’re probably many experienced consultants out there who’re  just readers or perhaps they don’t want to be bothered with silly questions. I don’t see Jeff actively participating on OTN forums (even though I think he had some postings in the past) – probably for that same reason.

Thank you everyone listed below! Excellent job!  Best of luck to all of you!  I also want to mention David T. and anyone else not listed.

	Kishore Guggilla (1775)
	Stijn Gabriels (1080)
	John Minkjan (990)
	Madan Thota (950)
	Turribeach (920)
	Christian Berg (635)
	Naresh Meda (625)
	gerardnico (605)
	mma1709 (590)
	wildmight (505)

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.

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.