I’m looking forward to trying this out and for the various bug fixes that we’ve had to work around in the previous versions of 11g.

It seems that the ability to apply a custom format mask (e.g. #,###0;-#,###0;0) to a column and have it apply to a pivot table view is broken in version 11.1.1.5. Oracle have confirmed this is an unpublished bug (13054445) so we are stuck with it for the time being until 11.1.1.7.0 comes along.

It seems this feature never really worked properly and you could click it, click ok, come back to the dialog later and it would be unticked again.

Oracle are now saying that this feature is obsolete and has been replaced by a better way of handling dimension-only queries. It seems the checkbox is hanging around in the UI without doing anything! Maybe it will be gone when 11.1.1.6 comes along?

More info on the Oracle Support site if you really need it: Doc Id 1394335.1 and Bug reference 13341484.

The system in question was set up with authenication against the company’s MS Active Directory via LDAP so that seemed like the most likely place to start looking.

After being assured that none of the LDAP configuration had been changed in Weblogic Console we figured it must be something external, within AD itself.

A bit of poking around with Softerra LDAP browser pinpointed the cause: the IT Support department had ‘helpfully’ moved the equivalent of the BISystemUser account to a different Base DN so it no longer sat alongside the rest of the users. This is a big no-no as it must be in the same place as the rest of the users because we can only specify one Base DN within Weblogic. After moving the user back to the correct place, connectivity was immediately restored and the problem went away.

The IT Support dept were suitably chastised and now everyone is happy again.

If you would be interested in attending please drop me a note using the contact form to register your interest. All are welcome!

Cheers!
Paul

UPDATE – I now have some space reserved in a venue and a few people have expressed an interest including a certain Mr Rittman. Please spread the word to anyone working in the field. The venue is near Chancery Lane / Farringdon and will be disclosed to those who have been in touch.

[nQSError: 77005] An invalid parameter was passed to the nQWebIBotAPI.dll. Verify that the Agent configuration is correct.

When you install the client tools it creates a ‘lite’ version of the full server install using may of the same files as the full install. One thing that isn’t present is a JavaHost so it is necessary to point the Admin Tool at a JavaHost running on another machine. To do this I edited:

C:\Program Files\Oracle Business Intelligence Enterprise Edition Plus Client\oraclebi\orainst\config\OracleBIServerComponent\coreapplication\NQSConfig.INI

In the [JAVAHOST] section I put:

JAVAHOST_HOSTNAME_OR_IP_ADDRESSES = “x.x.x.x”:9810;

where x.x.x.x is the IP address or fully qualified address of the BI Server.

After restarting the Admin Tool I was able to import the cubes as expected.

Here you can see how it’s done:

First create a simple request. On the results tab I’ve added 2 additional Compound Layouts. For layout 2 I add some content and set the background colour for ease of identification.

For layout 3 I do a similar thing but use a different colour.

Back on the original (default) Compound Layout I add a view selector. Within the view selector properties we can now choose the other Compound Layouts as well as ‘None’ to show nothing, which I guess people might want as the initial view when arriving on the dashboard page.

Here we can see the result of switching between the views using the view selector:

It’s a nice piece of functionality I think you’ll agree.

opatch version

If you see a version number and OPatch succeeded then the PATH variable is set up correctly. If not, edit the environment variable accordingly. Also check that ORACLE_HOME is set correctly.

Next we need to check the patch inventory is accessible:

opatch lsinv -jre %ORACLE_HOME%\jdk\jre

If this command does not complete successfully then there is a problem and you shouldn’t continue any further. You should see details of any previously applied patches followed by the message OPatch succeeded.

Unzip the patch and copy to the server somewhere [In this example we are installing patch 9884975 which has been placed in D:\incoming\Patches]

Depending on the patch contents you may need to stop the Admin and any Managed servers. I tend to do this anyway irrespective of the patch contents. Once that’s done…

cd D:\incoming\Patches\9884975

opatch apply -jre %ORACLE_HOME%\jdk\jre

(you can optionally add the -verbose switch to the above command if you want more logging and output)

Check the new patch appears in the inventory:

opatch lsinv -jre %ORACLE_HOME%\jdk\jre

Note that logging for OPatch can be found here:

%ORACLE_HOME%\cfgtoollogs\opatch

Finally restart the Admin server and all Managed servers to bring the system back up.

The response file for OCM configuration does not exist (or) is not readable. Please provide a valid response file.

In this environment we were not using OCM so it hadn’t been configured. It seems OPatch will create a new instance of OCM at %ORACLE_HOME%\ccr but it won’t have the necessary response file.

The fix was simple – run this command:

%ORACLE_HOME%\ccr\bin\emocmrsp.bat -no_banner -output S:\out.rsp

and then apply the patch by referencing the response file created above:

opatch apply -ocmrf S:\out.rsp -jre %ORACLE_HOME%\jdk\jre

Hope this helps someone out there.