Learn Discoverer Blog

Discoverer 10.1.2.3 CP4 is available again

2009-04-30T21:02:00.006-05:00

Last updated: May 5, 2009
I am delighted to be able to let you know that CP4 (patch number 7595032) is no longer password protected and the issue with the non-English language versions (see below) has been resolved. You are therefore free and encouraged to apply this patch.

By the way, this patch has all of the updates from 10.1.2.2 CP8 and many more.

Important Note:
Please note that if you are planning on installing CP4 that you will also need to install a patch for JDBC. I have made a comment on this in this posting and will post more information shortly.

Last updated: May 4, 2009
The latest information I have on this is as follows:

It was initially communicated that it only affected a small subset of customers as it was thought to only affect Japanese customers using Discoverer Plus. It was later discovered that some other locales were also affected.

Customer's were later updated with: Note: CP4 has temporarily been withdrawn due to a late breaking regression tracked in Bug 8477401 NLS: Discoverer Plus Always Runs In English Even If Japanese Locale Is Set'.

This can potentially affect all non-English locales. Oracle Support cannot provide a password or give access to the patch until the regression is corrected and the patch is re-uploaded to MetaLink. If you have have already downloaded the patch and use the English locale, then you should not be affected and can continue using the patch. This note will be updated when the updated patch is released.

Original Posting made: April 30, 2009
If you are vigilant and keep up with Oracle's cumulative patches and this blog (see here) you will be aware that CP4 (patch number 7595032) came out a couple of days ago.

Earlier today I noticed that it has now been password protected so I contacted Oracle. Here is what they told me:

CP4 has temporarily been password protected due to a late breaking regression tracked as bug number 8477401: Discoverer Plus Always Runs In English Even If Japanese Locale Is Set. This should only affect a small subset of customers. We are trying to get this password protection removed asap since it only affects a narrow band of customers.

Oracle plans to have this password protection removed quickly so it could even be removed before the information filters out too far. I will let you know when the password requirement has been lifted. If you are using English then you should go ahead and request the password as you won't be affected.

Please note that if you are planning on installing CP4 that you will also need to install a patch for JDBC. I have made a comment on this in this posting and will post more information shortly.

Michael presenting at ODTUG Kaleidoscope

2009-04-28T16:25:00.009-05:00

In June, I will be at the ODTUG Kaleidoscope conference between June 21 and June 25 in Monterey, California, where I will be presenting a paper entitled Maximize your investment in Discoverer. If you happen to be going please look me up. I will be presenting the same paper and also sitting as a panelist on the Business Intelligence / Data Warehousing Panel.

I am also scheduled to appear at the Baton Rouge Oracle Users Group meeting in July and have submitted a paper for Oracle Open World which is in October in San Francisco. I will provide more information on ODTUG, BROUG and Open World as the times draw closer.

For the eagle eyed among you, you will notice that originally this posting said that I was also going to be at the IOUG / OAUG Collaborate conference in Orlando next week. Unfortunately, something came up at the last minue which has prevented me from attending. This is the first time in 10 years of going to conferences that I have had to cancel an appearance like this. However, the good news is that Mike Durran from Oracle and Mark Rittman have agreed to step in and give my presentation for me. More on this to follow.

Michael is now a US citizen

2009-04-28T16:19:00.003-05:00

Hi everyone
I thought I would let you all know that last Friday afternoon in Nashville I took the oath to become a citizen of the United States. This is such a privilege and honor for me and something I have been looking forward to for quite some time, ever since I first started coming here for business way back in 1994.

I emigrated to the United States in 1999 while working for Logitech as their world-wide manager of business intelligence. Within a few months of my arrival I met Darlene and we were married within the year and have been together ever since.

We moved to Tennesses 5 years ago when we formed Armstrong-Smith Consulting and bought ourselves a small ranch so that we could enjoy the fine weather and get away from the hustle and bustle of consulting when time would allow. If you would like to see a few photographs of our place you can find them here on the About Us page of our website.

Cumulative Patch 4 for 10.1.2.3

2009-04-28T10:28:00.008-05:00

I am very pleased to announce that Oracle have released the eagerly awaited cumulative patch 4 for Discoverer 10.1.2.3 (patch number 7595032). When compared to CP2, almost 80 bugs have been fixed including the bug that was preventing usres from logging in correctly after applying CP3 (see here).

So far this has been released for the following platforms:

Microsoft Windows 32-bit
Linux x86 (works for both 32 bit and 64 bit)
Sun Solaris (64-bit)
HP-UX PA-RISC (64-bit)
IBM AIX Based Systems (64-bit)

There is also a very important note inside the readme regarding installing an interim patch. Here is the necessary information:

Please apply the JDBC patch p4398431_10105_GENERIC.zip for bug 4398431(release 10.1.0.5).This patch needs to be applied to all Oracle Homes, i.e. Infrastructure home as well as all related midtier homes.

Bug 4398431 - HANG WHEN RETRIEVING A CONNECTION FROM THE IMPLICIT CONNECTION CACHE

Then proceed with applying the current patch.

The following postings have been updated:

Oracle buys Sun

2009-04-21T10:52:00.005-05:00

If you haven't already heard, Oracle has announced (see here) that it has entered into an agreement to acquire Sun Microsystems (Sun).

My good friend Mark Rittman has a very good article on his blog (see here).

According to the Oracle press release:

The acquisition combines best-in-class enterprise software and mission-critical computing systems. Oracle plans to engineer and deliver an integrated system—applications to disk—where all the pieces fit and work together so customers do not have to do it themselves. Customers benefit as their system integration costs go down while system performance, reliability and security go up.

So what do you make of it? Personally I think it's a great move and will only strengthen Oracle's hand when it comes to vying with Microsoft in the marketplace. I think it was a deal that was always going to happen as Sun's Java is a product that means an awful lot to Oracle as most of their products require it to run effectively.

Of course, this also means that Oracle will now own the Solaris brand of hardware. So if the deal does go through, and I don't see why it should not, you will then be able to get one-stop shopping for hardware and software from the same vendor.

Personally, I say this is a great deal for Oracle and an even greater deal for Oracle's customers.

Charles Phillips, President of Oracle, today said the following:

Oracle's ownership of two key Sun software assets, Java and Solaris, is expected to provide our customers with significant benefit. Java is one of the computer industry's best known brands and most widely deployed technologies. Oracle Fusion Middleware is built on top of Sun's Java language and software. Oracle can now ensure continued innovation and investment in Java technology for the benefit of customers and the Java community.

The Sun Solaris operating system is the leading platform for the Oracle database. With the acquisition of Sun, Oracle can optimize the Oracle database for some of the unique, high-end features of Solaris. Oracle is as committed as ever to Linux and other open platforms, and will continue to support and enhance our strong industry partnerships.

Our customers have been asking us to step up to a broader role to reduce complexity, risk, and cost by delivering a highly-optimized standards-based product stack. Oracle plans to deliver these benefits by offering a broad range of products, including servers and storage, with all the integrated pieces: hardware operating system, database, middleware and applications. We plan to preserve and enhance investments made by our customers, while we continue to work with our partners to provide customers with choice.

April 2009 Patch Levels for Discoverer

2009-04-20T11:36:00.008-05:00

Oracle is continually refining and upgrading Discoverer. Because of this refinement process, from time to time, Oracle periodically withdraws support for older releases. These are called obsolescence desupport documents and can be found on MetaLink.

I will summarize the major releases here, along with their patch and desupport numbers.

Discoverer 3.x - completely desupported. The terminal release was 3.1.36 for Administrator and Desktop and 3.3.62 for Plus and Viewer. You should migrate to Discoverer 10g Release 2 (10.1.2.2 or 10.1.2.3) as soon as you can. Note that there is no direct migration path from Discoverer 3.1 to Discoverer 10g Release 2, as you must migrate via 4.1.48.08. The obsolescence desupport notice on MetaLink is document 162402.1.

Discoverer 4.x (stand-alone, not as part of E-Business Suite) - completely desupported. The terminal release was 4.1.48.08. You should migrate to Discoverer 10g Release 2 (10.1.2.2 or 10.1.2.3) as soon as you can. The obsolescence desupport notice on MetaLink is document 231072.1.

Discoverer 4.x (with E-Business Suite) - desupported as of October 31, 2006. According to Oracle "since Discoverer 10g (10.1.2.0.2 - now 10.1.2.2 or 10.1.2.3) is fully certified, we HIGHLY recommend implementing or migrating to this release". Extended Support (ES) will continue until October 31, 2009. You are advised to migrate to Discoverer 10g Release 2 as soon as possible. The obsolesence desupport notice for Discoverer 4i against E-Business Suite is MetaLink document 337576.1.

Discoverer 9iAS (9.0.2) - completely desupported as of July 1, 2008. The terminal release was 9.0.2.54.10. You are urged to upgrade to Discoverer 10g Release 2 (10.1.2.2 or 10.1.2.3) as soon as you can. The obsolescence desupport notice for Discoverer 9iAS is MetaLink document 162403.1.

Discoverer 10g Release 1 (9.0.4) - ECS support was withdrawn December 31, 2006. The recommended release is 9.0.4.46.00 (Application Server 9.0.4.3). Extended Support will continue until December 31, 2009, however you should upgrade to Discoverer 10g Release 2 as soon as you can. The obsolescence desupport notice for Discoverer 10g Release 1 (9.0.4) is MetaLink document 295948.1.

Discoverer 10g Release 2 initial (10.1.2.0.0) - The terminal release is 10.1.2.45.46c. You can upgrade to 10.1.2.48.18 by applying the 10.1.2.1 patchset which will bring you to the 10.1.2.0.2 code level (see below). No ECS or ES dates have been announced for 10.1.2.0.0. The support notice for Discoverer 10g Release 2 is MetaLink document 329361.1.

Discoverer 10g Release 2 production (10.1.2.0.2) - This is the current and most up-to-date release and the one you should be on if you can. Out of the box the base version you will get is 10.1.2.48.18. Notwithstanding the fact that this is the current version it is also a brilliant piece of software. Having installed the base release you need to upgrade to either 10.1.2.2 (10.1.2.54.25) or 10.1.2.3 (10.1.2.55.26) and then apply the most recent cumulative patch. No ECS or ES dates have been announced for this release. The support notice for Discoverer 10g Release 2 is MetaLink document 329361.1.

Notes: the definitions of ECS and ES can be found on MetaLink in note 187553.1

Be careful when upgrading to Java 1.6

2009-04-17T00:14:00.009-05:00

If you install Discoverer 10g out of the box you will get Java 1.4 on the server.

Last year Oracle announced that the server was now certified with Java 1.6 and issued a MetaLink note complete with instructions on how to upgrade the JVM.

On my travels, I have noticed that some administrators do not read the release and installation notes properly and overlook the fact the configuration.xml (found in $Oracle_Home/discoverer/config) needs to be updated as well. If you only install a new java executable but leave the configuration.xml file untouched you will run into serious user interface issues. One such problem is that parameter values will no longer be displayed from your user's last run or from when the worksheet was created thus causing your end users a great deal of anxiety.

An application server in such a state will also run much slower too, so please make sure you update the configuration.xml correctly.

To help you, here is the JVM section from the application server running on my own laptop:

< name="sun" classid="clsid:CAFEEFAC-0016-0000-0012-ABCDEFFEDCBA" plugin_setup="https://asclaptop0.learndiscoverer.com:7778/jpi/jre6u12.exe" version="1.6" versionie="1,6,0,mn" type="application/x-java-applet" plugin_page="http://java.com" disco_archive="disco5i.jarjar" d4o_archive="d4o_double.jarjar">

Notes:
1. This is all one line with no line breaks or carriage returns. There should also be no space following the leading or before the last brackets.

2. I have spaces to make sure that you can see the text and to stop your browser interpreting this as HTML.

3. The version number 12 only appeard in one place, in the classid switch.

The areas of importance are these switches:

classid
plugin_setup
version
versionie
plugin_page

In the following help I will show you the settings for Java 1.6.0_12. All of the switches are enclosed in double quotes.

classid: this complete switch has 36 characters broken down as follows:

first 9 always CAFEEFAC- all in uppercase
next 5 are always 0016- meaning Java 1.6
next 5 should be 0000- meaning Java 1.6.0
next 5 should be 0012- meaning release 12 (only place this is referenced)
last 12 should be ABCDEFFEDCBA again all in uppercase
full switch is: classid="clsid:CAFEEFAC-0016-0000-0011-ABCDEFFEDCBA"

plugin_setup: this switch should be fully qualified domain name pointer to the Java executable on the server. Even though this switch always has /jpi/ in the pointer the actual executable must be stored in /jpi/bin/ under the $Oracle_Home for the middle tier. The name of the executable can be anything you look but must be the same as the executable stored in $Oracle_Home/jpi/bin.

version: this switch should be 1.6 with a period between the two numbers

full switch looks like this: version="1.6"

versionie: this switch should be "1,6,0,mn" this time with commas between the 4 elements. Yes, mn should be used and not 12 as you might think.

full switch looks like this: versionie="1,6,0,mn"

plugin_page: this switch should just be http: //java.com and not a pointer to the complete version as it was in 1.4

full switch looks like this: plugin_page="http://java.com"

After you have upgraded the server to Java 1.6 I recommend you go to each of your user machines and clear the local Java cache. Discoverer will then ensure that they have the correct applet and will send down the right Java version the first time the user connects.

If your users have an earlier version of Java installed or no Java installed then the first time that they connect to Discoverer on an application server that is running Java 1.6 they will be prompted to install it. All they have to do is follow the on-screen prompts and they will be ok. If your users don't have administrative rights over their local PC or if you are making them connect via a Citrix terminal server then your administrator will need to install JVM 1.6 for them.

No more cumulative patches for 10.1.2.2

2009-04-16T23:41:00.005-05:00

If you have been keeping up with the latest information for Discoverer on Oracle MetaLink you will have noted that Oracle recently announced that cumulative patch 8 for 10.1.2.2 is the last one for that platform and that the platform currently being developed is 10.1.2.3.

If you haven't already upgraded to 10.1.2.2 you should skip it and proceed direct to 10.1.2.3. The steps to installing 10.1.2.3 on a native 10.1.2.0.2 are identical to the steps that you would have to apply to install 10.1.2.2. This means that if you are using an infrastructure then you will have to upgrade the metadata repository from 10.1.0.4 to at least 10.1.0.5.

If you have already installed 10.1.2.2 and any of the cumulative patches the good news is that 10.1.2.3 (patch 5983622) will install directly on top as there is no need to de-install anything, the upgrade will take of it for you. After you have upgraded to 10.1.2.3 you should then proceed directly to install cumulative patch 2 (patch 7198716).

You might be wondering why I say to should upgrade only to cumulative patch 2 when cumulative patch 3 was released earlier this year. This is because there are some bugs in cumulative patch 3 and you are advised to wait until cumulative patch 4 which, by the way, I have heard is due for release within the next 2 to 3 weeks. Just as soon as it released I will update my master patch blog note.

Clamping Down Discoverer

2009-03-14T16:44:00.004-05:00

Performance is often a big issue with Discoverer especially when Discoverer users share resources with other system users. It is often said that Discoverer must always use a separate reporting database because the Discoverer users would slow down the production system. This is rubbish; there are some good reasons for putting Discoverer on a separate system, but performance is not one of them.

Much better is to put all your system resources into one database and then clamp down Discoverer so that it cannot interfere with other processes. You can reduce the priority or limit the CPU; you decide what database resource Discoverer should use and when it should use it.

This post describes how to clamp down the Discoverer so that it does not slow down the rest of the system.

Resource Consumer Groups

The Oracle Database Resource Manager provides essential functionality to help you do this. It allows you to manage the hardware resources that are allocated to a database session. The Resource Manager provides a flexible way to control the Discoverer sessions because it allows you:

limit the CPU or I/O used by a session
lower the priority of session
terminate sessions that use too much resource
terminate sessions where the optimizer estimates that the SQL run time will be over a threshold

Even better, the resource scheme used can be changed dynamically, so that you can for example, have one resource allocation for during the day and another for night time and weekends.

Setting up a resource plan can be quite complex but fortunately there is a default SYSTEM_PLAN provided which has a low priority group into which you can add the Discoverer sessions. All other sessions will use the default consumer group so that any Discoverer session in the low priority group will only use CPU not consumed by other database sessions.

A listing of the plans and consumer groups available in the database can be obtain from the DBA_RSRC_PLANS and DBA_RSRC_CONSUMER_GROUPS views.

By default the Resource Manager is not enabled. So first you need to enable the Resource Manager by setting the database initialization parameter to a resource plan:
RESOURCE_MANAGER_PLAN=SYSTEM_PLAN

Alternatively, you can activate the Resource Manager on the fly by entering:
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'SYSTEM PLAN'

Next you need to ensure that the Discoverer sessions are added to the low priority consumer group. There are basically two ways that you can do this; using the consumer group mapping functionality to automatically add the session to the consumer group when the session is created in the database; or run an initialization procedure at the start of the session to switch the consumer group from the default group to the low priority group.

Consumer Group Mappings – The database lets you set up a mapping between session and consumer groups. Many new mapping options were added in Oracle 10g and therefore on databases prior to 10g the mapping option you need may not be available. A mapping that automatically adds sessions to a consumer group can be created using DBMS_RESOURCE_MANAGE.

There are lots of mapping options available. You can add all the sessions create by a user into a consumer group. For example, to add all the sessions created by the DISCO_USER database user into the low priority consumer group the following call to the DBMS_RESOURCE_MANAGER package can be used:

DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING
(DBMS_RESOURCE_MANAGER.ORACLE_USER, 'DISCO_USER', 'LOW_GROUP');

You can add all the sessions created by a particular program. For example, the sessions created by the Discoverer Desktop program can be added using:

DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING
(DBMS_RESOURCE_MANAGER.CLIENT_PROGRAM, 'dis51usr.exe', 'LOW_GROUP');

You can also add sessions by service name, so here you would define a service name in the TNSNAMES.ora files used by Discoverer and map the service name to a resource group.

Initialization Procedure - This is the method we use. A procedure is run at the start of every Discoverer session which switches the consumer group. Because we are in an Oracle Applications 11i environment we use the ‘Initialization SQL Statement – Custom’ system profile to call the initialization procedure rather than a trigger. The procedure includes the following statement:

DBMS_SESSION.switch_current_consumer_group('LOW_GROUP',v_varchar2_240, FALSE);

to switch the session to the lower priority consumer group.

The initialization procedure gives you the best control over the consumer group setting. For example, you can set the priority of scheduled Discoverer sessions to be lower than the priority of regular sessions.

RAC Nodes

Real Application Clusters (RAC) provide an effective way of segregating Discoverer from other processes. Typically you would have a database node dedicated to processing Discoverer reports. Discoverer can then be directed to the dedicated node by setting the RAC node in the TNSNAMES.ora file on the Discoverer Application server (and on the desktop if Discoverer Desktop is used). You can use service names to specify preferred and failover nodes.

Using a dedicated RAC node is the cleanest way of separating Discoverer from other processing in a RAC environment however, if you use parallel processing in your Discoverer reports then some further configuration is required.

By default on a RAC node any SQL statement that uses parallel processing will parallelize the workload by running slave processes on all RAC nodes in the database. So if the parallel_max_servers database parameter is set to 8 then 8 parallel processes will be started on each RAC node in the database. That's great if you want your Discoverer report to use CPU resource across all the RAC nodes, but if you want Discoverer just to use the dedicated RAC node then in Oracle 10g you need to set up a RAC instance group. In 11g it’s a bit easier as the nodes are service aware and only run the named service.

1. For example in 10g, if PROD is the database instance and PROD4 is the dedicated RAC node then an INSTANCE_GROUP called DISCO for the Discoverer dedicated node can be defined by including in the database initialization file:
PROD4.INSTANCE_GROUP=DISCO

2. Then in the Discoverer initialization procedure include the following statement:
EXECUTE IMMEDIATE 'ALTER SESSION SET PARALLEL_INSTANCE_GROUP = ''DISCO''';

The Discoverer processes will then join the DISCO parallel instance group when the process is started and any subsequent parallel SQL run by this process will only use the RAC nodes in the DISCO instance group.

Temporary Tablespace

A Discoverer report that is very large or has been badly written can use a lot of temp space. The database uses temporary tablespace when a database sort is too large to fit in memory and so if Discoverer has to sort lots of data for example in a hash join then it will use temp space. The size of the temp space needs to be controlled to stop the disks filling up and hence a maximum size limit for the temporary tablespace should be set.

This is a problem if Discoverer is sharing the temp space with other processes. When a Discoverer report runs out of temp space then it will fail with ORA-01652: Unable to extend temp segment. The problem is that the temporary tablespace is a database user resource and so is shared with other processes that use the same temporary table space.

Hence when Discoverer processes are sharing a database with other processes it is important that the Discoverer processes use a separate tablespace. Otherwise one or more rogue Discoverer processes can gobble up all the temp space causing another process to fail when there is no temp space available.

Now if your Discoverer processes always connect to the database as separate database users then the solution is easy; you create one or more separate temporary tablespaces for these database users. Then the Discoverer processes may still fail with the ORA-01652: Unable to extend temp segment error but at least other processes will be unaffected.

However, where Discoverer is used with the e-Business Suite (and also in many other systems) Discoverer connects to the database using a common database user. In the e-Business Suite all processes connect as the APPS database user and therefore by default all processes share the temporary tablespace associated with the APPS database user. The OLTP processes probably do not use any temp space but interface and batch processing often use temp space and could error as a result of Discoverer processing.

The solution is not easy and different solutions may be required for different systems, but where Discoverer is implemented with the e-Business Suite a separate temporary tablespace can be implemented as follows.

1. Create a new user with a limited tablespace.

CREATE TEMPORARY TABLESPACE TEMP_DISCO TEMPFILE SIZE AUTOEXTEND OFF;

CREATE USER APPSDISCO IDENTIFIED BY DEFAULT TABLESPACE TEMPORARY TABLESPACE TEMP_DISCO ACCOUNT LOCK;

2. Create an initialization procedure for the Discoverer which changes the current schema to the APPSDISCO user for the Discoverer process. The current schema defines which database schema is used as the default schema where no schema is specified in front of a database object. Consequentally the temporary tablespace used is the temporary tablespace associated with the APPSDISCO user.

PROCEDURE initialize
IS
BEGIN
IF SYS_CONTEXT('USERENV','MODULE') LIKE 'Disco%' THEN
EXECUTE IMMEDIATE 'ALTER SESSION SET CURRENT_SCHEMA=APPSDISCO';
END IF;
END initialize;

3. Call the initalization procedure from the ‘Initialization SQL Statement – Custom’ system profile for all the responsibilities that use Discoverer. So if your initialization procedure is held within the DISCO_UTILITIES_PKG PL/SQL package then the profile would be set to:

begin disco_utilities_pkg.initialize; end;

However, there are some complications that may need to be addressed:

The SYS_CONTEXT('USERENV','MODULE') only works in Oracle 10g. In Oracle 9i you need to check in the V$SESSION table.

Although Discoverer puts the APPS schema in front of all the database objects I found that there were some database bugs in the version of the database I was using (Oracle 9i) and I had to create some synonyms for some of the APPS objects, for example, to get all the Discoverer reports to run I had to create synonyms in the APPSDISCO schema for all the packages used by functions mapped into the EUL.

Again, although the Discoverer processes still connect as the APPS user and therefore have all the APPS database privileges I found that database/Discoverer bugs caused privilege errors. To workaround this I had to grant privilege on some APPS database objects to the APPSDISCO user.

Conclusion

Where Discoverer is reporting on transactional data then Discoverer should use the same database as the transactional system. A single database allows Discoverer to report on real-time data and saves all the complications of replicating and managing separate databases.

A single database allows more efficient use of the hardware resources by allowing Discoverer to use spare CPU that would otherwise be wasted. Long running Discoverer processes can run at lower priority than other processes in the system increasing the overall throughput of the system. Provided Discoverer has been properly clamped down then the Discoverer processes will not affect other processing in the system.

You can go further and separate Discoverer scheduled processes from interactive Discoverer processes. Then you can run the scheduled larger Discoverer reports at a lower priority and separate temp space than the interactive reports.

When Discoverer Users and management know that they will not be able to affect the performance of the system as a whole by running Discoverer reports, they will then have confidence to build and run more complex reports making greater use of the Discoverer reporting system.

Caching data for Discoverer

2009-02-25T15:54:00.005-06:00

I thought it was about time for another post and this one is about how you can cache data for use in Discoverer.

Caching is just one strategy that you can use to make your Discoverer reports run faster. It is a bit like bribing a wayward child. You give it some cash and it will get on with the job a bit quicker. But the performance improvement doesn't come for free. You have to load your cache first and keep it ready for the Discoverer report to use which will use additional resource.

Caching is big a topic; too big to cover in a single post. There are different levels where you can cache data for Discoverer reports. You can use OracleAS Web cache to hold HTML web pages generated by Discoverer Viewer. You can cache data in the database ready for use by Discoverer. You can schedule Discoverer workbooks to run so that the results are cached ready for the user to access.

This time I will look at how you can cache data in the database where you hold records in a cache ready for Discoverer to use. Before I go into the details I think it is important to say that caching is not a technique you should use to make a badly written report run faster. If it badly written and inefficient the solution is to fix it, not add more complexity by caching data to try and make it run faster. Nor should you use caching to try and make one tricky report run a bit faster. It is something you need to design into your Discoverer environment at the beginning to give you the maximum benefit.

Caching data in the database is where records are cached in the database ready for Discoverer to use. Again there are many techniques you can use; some of these techniques depend on new features introduced in Oracle 11g. A database cache can make a big difference to the performance of your reports as it will enable Discoverer to run simpler SQL for the reports which will it turn give better performance. But, like with all performance work, it all depends on many factors; a database cache could make no difference or make your report run slower. It is all about using the right technique for the right situation.

Basically there are four points where data can be cached for a Discoverer report:

Before the user logs on
When the user logs on
On-the-fly when a report runs
In a SQL result cache

Unfortunately there is no eul_trigger$post_open_document trigger available in Discoverer or any mechanism that would allow you cache data when a workbook was first opened or run.

Caching data before the user logs on

Here the data is cached overnight or at regular intervals so that it is available when a user logs on.

The traditional technique is used is a materialized view. Materialized views (MVs) have two really cool features. Firstly, they can be automatically refreshed either on commit, or periodically or on demand. Secondly, they can use query redirection where an SQL statement that references the underlying tables but which only requires summary information is re-directed to the MV.

Oracle 11g introduces some new features for materialized views which could be very useful for Discoverer developers. One of the most interesting is that you can set up an OLAP cube in the database that summaries your data and then use a MV to redirect queries to the OLAP cube. Hence you could use the Discoverer relational tools to gain the benefits of running against an OLAP cube without having to switch to the Discoverer OLAP product.

Having said that, I would avoid using MVs and would only use them as a last resort. Here are some of the reasons why:

Normally, you cannot use an ‘on commit’ refresh on the MVs and therefore the information in the MVs is always older than the underlying tables. This means the results obtained from MVs are always slightly out of date.
Also, often you cannot use an incremental refresh on the MVs because this requires a primary key defined on the underlying tables. So the MVs are often completely refreshed periodically and this needs a lot of database resource.
When the MV is refreshed you don’t know which users will be accessing the information and therefore it is difficult to ensure the data security available in the underlying tables is replicated in the MVs.
Frequently the query used to define the MV is complex and therefore the database is not able to use query redirection because the database must be able to match query being redirected to the query defining the MV.

I have seen a number of projects come unstuck because they have tried to improve performance by making some of their reports into MVs. The result is many complex MVs which are constantly out of date and need huge database resources to refresh.

I have found the best approach is to design a small number of simple MVs that summarise some core tables that can be used by many reports.

Caching data when the user logs on

Here the data is cached when the user logs onto Discoverer. The mechanism that you use to run a PL/SQL procedure to cache the data will depend on your environment but could be either:

a database trigger that checks whether the current session is a Discoverer session
the Oracle Applications 11i ‘Initialization SQL Statement – Custom’ system profile can be used to run an initialization PL/SQL procedure for Discoverer sessions
an eul_trigger$post_login trigger is used to run a PL/SQL procedure.

When the session initialization process runs it can run SQL to cache data from the session which then can be used in all subsequent Discoverer reports. There are different places that you can cache data in the database.

Database Contexts – This is useful for storing session parameters that you can use in subsequent database queries.

Temporary Tables – You use one or more temporary tables as a cache for the Discoverer. The table then can be used within the Discoverer reports or as a base table for a list of values. The data in the temporary tables will only be visible to the current Discoverer session so is useful for storing information specific to the user that can be used to improve performance in reports.

PL/SQL arrays – This is useful for caching data that is required by the PL/SQL functions run from Discoverer. See the next section for more details of this technique.

For example, if many of your queries need to use an ORG_ID associated with a user then create a context namespace using:

CREATE OR REPLACE CONTEXT DISCO USING DISCO_UTILITIES_PKG;

Then in the process initialisation obtain the ORG_ID for the user and set the context using:

dbms_session.set_context('DISCO', 'ORG_ID', v_org_id);

You can then check the context in a condition in your view or Discoverer folder using SYS_CONTEXT('DISCO', 'ORG_ID') .

If you have lots of contexts that you need to set at initialisation then it is useful to put all the queries to obtain the contexts values in a view then you can set all the contexts using:

FOR xcon IN (SELECT context_name, context_value
FROM xxmod_dis_context_value_v)
LOOP
dbms_session.set_context('DISCO', xcon.context_name, xcon.context_value);
END LOOP;

Then any changes to the context set up can be accommodated by simply changing the view.

However, where you need to save many ORG_IDs or, for example, a list of PRODUCT_IDs that a user can see then the technique to a temporary table. For example, you can create the temporary table using:

CREATE GLOBAL TEMPORARY TABLE PRODUCT_ID_TMP
( PRODUCT_ID NUMBER(10),
CONSTRAINT PRODUCT_ID_TMP PRIMARY KEY (PRODUCT_ID) ENABLE
) ON COMMIT DELETE ROWS;

Then just insert the product ids into the table in the initialisation PL/SQL procedure and use the table in a Discoverer folder or view just like a normal table. When the session finishes the data is deleted.

Caching Data on-the-fly

Here data is loaded by the first call to a PL/SQL function into a PL/SQL array. Subsequent calls to the function use data from the internal array. This technique is very useful for converting internal codes into text descriptions that are required in a report. For example, in an Oracle Applications 11i environment where you need to make repeated lookups into tables such as FND_FLEX_VALUES_VL and FND_LOOKUP_VALUES to obtain segment and attribute descriptions. It can also be used to store values that are hard to obtain but need to be used many times in a report.

Taking a generic approach using a single cache_lookup function gives the best results. The cache_lookup function can be defined like this:

FUNCTION cache_lookup(lookup_type IN VARCHAR2,
lookup_code1 IN VARCHAR2) RETURN VARCHAR2

The lookup_type parameter determines which SQL statement is used to obtain the data for the cache. The lookup_code1 is a bind variable for the SQL statement. The cache_lookup function is overlaid with multiple versions with different numbers of bind variables, because some lookups require multiple bind variables. For example, the call to

cache_lookup('LOOKUP_MEANING', 'MAR_STATUS', papf.marital_status)

obtains the marital status text from the FND_LOOKUP_VALUES table.

The function actually works by using DBMS_UTILITY.get_hash_value to hash all the input parameters together and check in a BINARY_INTEGER indexed PL/SQL array to see whether the value is in the cache. If it is not then the SQL statement is run and the value is added to the cache. Subsequent calls to the function with the same parameters retrieve the value directly from the cache.

Oracle 11g introduces the concept of a function result cache which provides similar functionality so this could be the way to go if you are using 11g.

There is always a trade-off between the overheads of making a call to a PL/SQL function against the benefits of caching the data also bearing in mind that the Oracle database is often very efficient at caching data internally when processing SQL statements.

However here are four reasons why I often use PL/SQL caching:

It’s quicker. Joining lookup tables in to query often makes finding an efficient execution plan difficult for the optimiser. The most efficient SQL is often to use a scalar query within the SELECT statement but this is not supported by Discoverer or in a materialized view. An alternative is to outer join the lookup tables but the outer join always generates less efficient SQL and cannot be used with an OR condition. Using a PL/SQL cache can be quicker because it removes all the lookup tables from the main SQL giving the optimiser the best chance of finding an efficient execution plan. But really it all depends on the complexity of the lookups as to whether you will see a performance improvement using a PL/SQL cache.
It’s quicker again. A Pl/SQL caches lasts for the duration of a session. Often running ad-hoc Discoverer involves run using similar queries many times. Your caches is loaded on the first query so subsequent queries are quicker.
Better instrumentation. This is the big bonus of using a PL/SQL cache. Especially, with Oracle Applications there are often errors encountered when processing the lookups. Sometimes, there is more than one description for the lookup code, or no description is found when one is needed. Finding the row that has caused the problem can be very difficult. With a PL/SQL cache you can build in instrumentation code that raises a meaningful exception when an error is encountered. Even better you can make this behaviour configurable so that for normal users lookup errors are ignored.
Less code. Less code is always good. By using a generic lookup function you can put all your lookups in one place. This function can then be called in views, Discoverer calculations and anywhere else where you need to convert a code to text.

Caching data in SQL result cache

This is a Oracle 11g technique that allows you to save the results of an SQL query (or subquery within a query) in an SQL cache located in the SGA. This is probably most useful to cache the results from a complex query fragment within your Discoverer views. For example, if the results from dept are complex and difficult to obtain you might define a view based on a query like this:

SELECT employee_name, dept_id …
FROM emp_table
, (SELECT /*+ result_cache */ dept_id, dept_name, …
FROM dept) dept
WHERE emp.dept_id = dept.dept_id

I haven’t had a chance to benchmark this feature so cannot make any claims for performance improvement but I believe it would help in some situations.

Word of warning about 10.1.2.3 and CP3

2009-02-20T09:04:00.006-06:00

Hello everyone
I have been monitoring and taking part in a thread (click here for thread) on the OTN Discoverer Forum concerning an issue with 8-character passwords not always being accepted in Discoverer 10.1.2.3 with CP3 installed.

Oracle Support have now confirmed that this is a bug and have posted it on MetaLink as bug number 8267360.

Basically - if you access the Discoverer login page for either Plus or Viewer with a URL parameter like &database=(TNS name) AND the user has exactly 8 characters in his / her password, then you will get an ORA-01017 logon denied, even though the password is correct.

These login bugs have been fixed with Cumulative Patch 4 (patch 7595032 on MetaLink)

If you are therefore on 10.1.2.2 with any cumulative patch or on 10.1.2.3 with CP1 or CP2 installed and you like to use the EUL switch in the launch URL you should install CP4, which was released on 28th April, 2009.

Jacob, I am indebted to you for bringing this to my attention.

February Ask Michael

2009-02-03T11:26:00.005-06:00

The January Ask Michael webinar was a great success.

The next Ask Michael is scheduled for Wednesday, February 11th at 3pm Central time. If you have not signed up or want to send me a question please use this link.

During the January webinar I answered a question on setting Discoverer preferences for Lee from the Corporation for National and Community Service in Washington. Here is what Lee said:

"I had asked for Michael's help regarding query restrictions. We had spent a number of days researching and applying Oracle MetaLink fixes to no avail. Michael's step-by-step explanation showed us a step we had missed and we look forward to 'curing' our production Discoverer during our next code update. We've tested Michael's solution in both of our test environments and it worked flawlessly! It's too late to save me from gray hairs, but at least our Discoverer report writers now aren't calling to complain about out failure to fix this issue"

I am delighted that I was able to help in this way. These online webinars are a free service offered by me and Armstrong-Smith Consulting to the Discoverer and Business Intelligence community. All you have to do is register in order to attend.

You can see all of our upcoming offerings such as webinars, training and conference attendance, on the ASC calendar page of our website.

See you on the 11th.

Cumulative Patch 3 for 10.1.2.3

2009-01-07T15:45:00.002-06:00

I am very pleased to announce that Oracle have released a third cumulative patch for Discoverer 10.1.2.3.

So far this has been released for the following platform:

Windows 32-bit
Linux x86 (works for both 32 bit and 64 bit)
HP-UX PA-RISC (64-bit)
HP-UX Itanium

The following posting has been updated:

Useful Patch Numbers

New Armstrong-Smith Consulting Web Site

2009-01-07T15:38:00.002-06:00

Hi everyone
I'd like to point you in the direction of our new website. We all think this is a vast improvment on our old website.

First of all we are no longer only focused on Discoverer. We are business intelligence. However, because most of you reading this entry are interested in Discoverer of course the new website is still the place to go.

By the way, there's still time to sign up for my Ask Michael Seminar series which kicks off next week on January 14th.

Ask Michael in 2009

2008-12-23T14:13:00.002-06:00

Starting in 2009, I will be hosting a free monthly webinar for all aspects of business intelligence and data warehousing. Of course, because I am considered the expert in Discoverer, a large amount of the time will be devoted to answering questions on this hugely popular tool.

The first webinar is scheduled for January 14, 2009

There is plenty of time to submit a question and / or register for the webinar so click here.

A couple of says before the webinar I will contact you with the username and password that you will need for access.

Remember - the webinars are free but you must register with me

ASC Training in Tennessee

2008-12-23T14:02:00.002-06:00

Hello everyone
I want to let you know about an exciting new inititiave that my company is starting in 2009. Because we know that many companies only have one or two staff that need our training and cannot afford to have us come on site, we will be offering the same trainng at our own premises starting January.

The training is built around the Higher Education EUL that we developed for SunGard and their clients. If you are unsure whether this would be suitable for you please email me for more details.

Note: Armstrong-Smith Consulting has partnered with SunGard and are the sole authorized partner able to offer this training.

Click here for more information, for prices or to make a booking. By the way if you are a member of the Nashville or Oklahoma City Oracle User Groups we will give each attendeed a 10% discount on the training price and give a further $50 donation to your user group when you complete the training. A Win-Win if you ever heard one!

If you are interested in this training, click here for the Agendas

If you would like more information please drop me an email.

Happy Holidays to everyone

2008-12-09T11:24:00.004-06:00

Hello everyone. I just wanted to drop you all a line and say thank you to everyone who follows my blog and wish you all very best wishes for the upcoming holidays to you and your family wherever you are in the world. Most of you I know are in the United States but I have a lot of dedicated followers in other parts of the world in countries like the United Kingdom, India, Canada, Australia, Germany, Denmark, China, Kuwait, Saudi Arabia, Russia and dozens more.

If I knew how to send you best wishes in your language I would.

I also wanted to let you all know that I will be starting several new services in 2009 and invite you to email me with your name and email address so that I can let you know when the services will start.

Because many of you have limited budgets and unable to travel for training and help, we are setting up on-line initiatives. One of the most exciting new ventures will be the making available our superb Discoverer training courses to on-line subscribers. We will be offering both our popular Administrator and End User classes for you to follow. We will also have a dedicated trainer available via telephone and email should you have issues.

Discoverer courses:

Discoverer Administrator - 14 hours on-line
Discoverer End-User - 20 hours on-line

Further, and these have been asked for many times, we will be offering the following brand new on-line courses:

Other Courses:

An introduction to SQL - 8 hours on line
An introduction to Data Warehousing - 8 hours on line
How to maximize your business intelligence investment - 8 hours on-line

These are generic courses not aimed at a particular product and will be very popular.

We will be placing a form on-line in the coming weeks but until then please send me an email with your name and I will make sure you get on our distribution list for these courses. Sending me an email in no way ties you in to buying a course and I will not give your name or email address to anyone else for any purposes. You will only be contacted by Armstrong-Smith Consulting.

Metalink Note 304192.1 and contexts

2008-11-20T15:35:00.007-06:00

Update: This metalink note has now been discontinued. Note 282249.1 gives information on how to pass parameter to a folder using the session client_info. The client_info is a database context available to all sessions in the USERENV namespace. Advantages of using client_info instead of a custom context is that you don't need to create the new context namespace at the database level and also the value of the client_info context can be seen in the V$SESSION dynamic view. However, it can only be used for one parameter and the client_info is used by many applications including the e-Business Suite so you run the risk of overwriting data already stored in the client_info.

This metalink note describes how to pass parameters into a custom folder or database view using stored procedures. The note has been around for quite a while, but as I will explain, the method used will never work reliably in all situations. The note suggests that you use two functions held in a package to set and get a parameter. You use a condition in the view or custom folder to retrieve the parameter, for example:

WHERE ENAME=SETPARAM.GET_PARAM1

Then use another condition in the workbook to set the parameter. The function always returns 1 so is always true.

1=SET_PARAM1(:"Parameter 1")

This approach expects that the SET_PARAM1 function will be called first because it uses constants and so can be evaluated without referencing any tables. However, this will only work if the query in the view or custom folder is not too complex. Once an SQL statement has been sent to the database you have no control over the order in which stored procedures are called. With complex SQL statements, for example, using CONNECT BY, the GET_PARAM1 function will be called first and will return either no value or the last value used.

There is NO reliable way of passing parameters from Discoverer into a custom folder or view using a single SQL statement because the database can call the stored procedures in any order. So any parameter added to the query by Discoverer will probably not be processed before the main body of the query held in a custom folder or view.

Database contexts provide a more efficient and reliable alternative. Database contexts work like session parameters, once the context is set it is available to use for the duration of the session. You can set them or change them using a separate Discoverer worksheet.

To implement Discoverer session parameters you will first have to create a context namespace in the database for the Discoverer contexts.

CREATE OR REPLACE CONTEXT DISCO_CONTEXT
USING EUL_US.DISCO_PKG
/

Then you need to create a package to enable you to set and retrieve contexts from in Discoverer.

CREATE OR REPLACE PACKAGE EUL_US.DISCO_PKG
AS
FUNCTION set_context(p_name VARCHAR2,
p_value VARCHAR2) RETURN VARCHAR2;
FUNCTION show_context(p_name VARCHAR2) RETURN VARCHAR2;
END disco_pkg;
/

CREATE OR REPLACE PACKAGE BODY EUL_US.DISCO_PKG
AS
FUNCTION set_context(p_name VARCHAR2,
p_value VARCHAR2) RETURN VARCHAR2
IS
BEGIN
dbms_session.set_context('DISCO_CONTEXT', p_name, p_value);
RETURN p_value;
END set_context;

FUNCTION show_context(p_name VARCHAR2) RETURN VARCHAR2
IS
BEGIN
RETURN SYS_CONTEXT('DISCO_CONTEXT', p_name);
END show_context;

END disco_pkg;
/

Once you have imported the set_context and show_context functions into the Discoverer EUL you are ready to set and retrieve your session parameters.

With this approach you set your session parameters in a separate worksheet from your main reports. For example, the following steps show you how to create a worksheet to define an effective date parameter:

1. Create a workbook based on any folder containing an item of type date.
2. Create a parameter based on a date.

3. Create a calculation to call the set_context function and set the effective date.

4. Remove the contents from the folder so that the folder just contains a parameter.
5. It is also useful to create another calculation retrieving the value of the parameter, so that the value entered for the parameter can be seen when the workbook is run.

The value of the context in a custom folder or view can be retrieved using a condition, for example:
TO_DATE(SYS_CONTEXT('DISCO_CONTEXT','EFFECTIVE_DATE'))

Every EUL of any complexity should use database contexts:

1. Using SYS_CONTEXT gives better performance. SYS_CONTEXT is an SQL function and therefore much quicker than using calls to PL/SQL.

2. SYS_CONTEXT can be used in any code; in views, PL/SQL code and custom folders. The function can also in the EUL and workbooks; you can import the function into the EUL (from the SYS schema) and use it instead of the SHOW_CONTEXT function. SYS_CONTEXT will always return the current value of the parameter for the session.

3. You can store all your parameters in the same database namespace, so there is no need to change any code if there is a need extra parameters.

4. You can set the database contexts to default values using a login trigger. Then the users only have to run the parameter worksheet if they need to change a session parameter. You can even store the last contexts used in a table, so that a new Discoverer session picks up the values used in a previous session.

However, one limitation of this technique is that Discoverer caches the results of some SQL such as the lists of values and so changing a session parameter will not change a list of values.

Discoverer 10.1.2.3 certified for use with E-Business Suite

2008-11-19T12:03:00.003-06:00

I am very pleased to announce that Discoverer 10.1.2.3 is now certified against both E-Business Suite 11i and 12i. You must however have applied at least cumulative patch 1 as the base version which you get following an upgrade is not certifed.

E-Business Suite Versions
For more information concerning Discoverer 10.1.2.2 and 10.1.2.3 and E-Business Suite 11i please look at MetaLink note number: 313418.1

For more information concerning Discoverer 10.1.2.2 and 10.1.2.3 and E-Business Suite 12i please look at MetaLink note number: 373634.1

I have also updated my master blog posting on Discoverer releases: http://learndiscoverer.blogspot.com/2008/04/most-useful-patch-numbers.html

Row Generators

2008-10-23T07:11:00.006-05:00

Thank you Michael for inviting me to contribute to your blog. I thought I would start off by talking about row generators and how to use them with Discoverer.

A folder that you can use as a row generator is always useful to have in an EUL. A row generator is just a folder that always returns a fixed number of rows. You can define a row generator either by using a database view or by creating a custom folder as shown below. There is a dummy item included in this row generator so that the folder can be joined to other folders in the EUL.

Lists of Values

There are many uses for a row generator but they are often most useful when creating a list of values (LOV) where there are a fixed number of values, for example, a Yes/No list of values. To create you LOV first create a new (complex) folder, then drag the N item from the row generator folder into the new folder. You then need to create a mandatory condition in the new folder to restrict the number of rows, for example, in this case N<=2. You can then create a calculated item to return the text used in the LOV. You can use DECODE to convert the number into a text string as shown below.

Then create a LOV item class based on the calculated item so that you have a folder that returns the required values as shown below.

Of course this is a very simple example. But in general you will find it easier to have one row generator folder and have complex folders for each LOV. It is easier to use a CASE or DECODE expression than create a new custom folder for each LOV.

Other useful examples are:

List of Values	Calculation	Condition
Days of the week	TO_CHAR(TRUNC(SYSDATE, 'D')+n-1, 'Day')	N<=7
Previous 12 months	ADD_MONTHS(TRUNC(SYSDATE, 'MONTH'), 1-n)	N<=12
Letters of the alphabet	CHR(65 + n-1)	N<=26

This last example where you have a LOV containing the letters of the alphabet is useful when you want to show an index on a text field, for example, bookname. You need to create a bookname_char calculated item, UPPER(SUBSTR(bookname,1,1)) and put this in the alphabet item class. You then need to create a hierarchy from the bookname_char item to the bookname item which will let you select the first letter of the bookname and then drill down to see all names beginning with this letter.

Fixing the number of columns

The row generator is also useful if you need to have a fixed number of columns in a crosstab report. For example you wanted 12 columns, one for each month in the year summarising employee earnings. Now, there will be some employees who do not have earnings for all months in the year. When the report is run for these employees there will be less than 12 columns. If you create a LOV folder for the months you need as described above and outer join the LOV folder to the report folder then you will always get a fixed number of columns in your report.

Pivoting

A row generator can be used to pivot a table or part of table. This is where you want to show values that are in different columns on separate rows.

For example, if your employee table has columns for the hours worked on each day in the week and you need a report showing the total hours on each day of the week by department. So in this case you need to pivot the hours onto separate rows. You do this by creating a days of the week folder that always returns 7 rows as described above. Make sure you also include the dummy item from the row generator folder. Then create a dummy item in your employee folder as shown below.

You can then join the employee table to the days of the week folder using the dummy item. Then in the workbook create a calculation to show the total hours for any day using:

SUM(DECODE("Row Generator 100".N,
1, Employees.mon_hrs,
2, Employees.tue_hrs,
3, Employees.wed_hrs,
4, Employees.thu_hrs,
5, Employees.fri_hrs,
6, Employees.sat_hrs,
7, Employees.sum_hrs))

You can then select the day from the days of the week folder, the department from the employees folder and the hours calculated item to get the sum of the hours for each day of the week.

Counting records many times

The row generator can be used to multiply rows when you want to count the rows several times.

For example, if you have a report that shows when users logged on and off your system but you want a chart showing the how many users are logged on during each hour during the day. This means that if there is a record showing user A logged on at 8am and logged off at 11:50am then this record needs to be counted 4 times, once for each hour the user was logged on.

You need to create an hours row generator folder as described above that returns the 24 hours in the day using an hours calculation shown below :

TO_CHAR(n-1,'fm09')

Now if the user logon and logoff times were held in a user_timings folder then you need to join the hours row generator folder to this folder using a dummy item as described in the previous section. This will multiple each row 24 times. Then a condition in the workbook can be used to return only the hours when the user was logged onto the system:

Hours BETWEEN TO_CHAR(TRUNC(logon, 'HH24'), 'HH24') AND TO_CHAR(TRUNC(logoff, 'HH24'), 'HH24')

You can then count the records and group sort on the hours calculation to return the data you need for the chart.

This of course assumes that all users log on and off on the same day. You would need a slightly more complex condition if users where able to logon and off on a different day.

Pictures of Darlene and Michael

2008-10-21T10:07:00.009-05:00

Many of you know Darlene, my wife, and I as the owners of Armstrong-Smith Consulting and the authors of the Oracle Discoverer Handbook. Here are some photographs of us taken in our offices recently:

Interesting condrum with indexed values

2008-10-16T10:51:00.005-05:00

As you know from a previous posting it is possible to create Discoverer lists of values to display a lookup description e.g. Department Name and return the primary key code namely, Department Id when using a list of values in a parameter.

What I have discovered today is something very intersting in the way that Discoverer does this and something that you ought to be aware of.

Let's say a bottle manufacturing company has a whole series of bottles which they describe using the color of the top. Some descriptions would be 1 Litre Blue Top, some 1 Litre Red Top and so on. Let's also say that they start out with code 10 represting 1 Litre Blue Top, and code 11 representing 1 Litre Red Top.

Inside Discoverer Plus, if a user has an indexed item in use and they choose to select using the Values option (see my original posting if you are unsure what this looks like) they will be presented with a list of values like this:

(1 Litre Blue Top) 10
(1 Litre Red Top) 11

What you may not be aware of is what Discoverer submits to the database. This is what will get submitted:

(((o100539.PRODUCT_DESCRIPTION) = '1 Litre Blue Top'
AND o100539.PRODUCT_CODE = '10'))

Yes, Discoverer actually adds an AND clause for BOTH parts of the equation. It searches for both the Code and the Description. I can see why this is happening. This is to solve the following problem:

Let's say the bottling company later decide to introduce an updated version of the 1 Litre Blue Top and decide to use code 20. Because there are two items with the same description, if Discoverer were to only submit this:

(o100539.PRODUCT_DESCRIPTION) = '1 Litre Blue Top' )

then both items would be returned in the query. The only way to guarantee to get the right combination would be for Discoverer to add the AND clause.

Somebody recently asked me why Discoverer didn't use an OR connector, like this:

(((o100539.PRODUCT_DESCRIPTION) = '1 Litre Blue Top'
OR o100539.PRODUCT_CODE = '10'))

If Oracle were to change the code to an OR condition then we would definitely get multiple rows returned so Oracle's choice of using an AND clause seems to be correct.

So why then am I bringing this to your attention. I'll tell you why.

Let's say the bottling company decides to rename the description for bottle 10 to this 1 Litre Top - Blue. No big deal you might think because there is still only one description for that code - wrong!

Let's say a user opens a workbook containing a worksheet that has a such an indexed parameter and that the last time it was used either the code 10 was selected or it is being supplied as the default value. Because the parameter already has the value displayed on screen all the user needs to do is to accept the current value and click Finish. Because the user does not reselect 10 and just clicks Finish what gets submitted to the database will still be the original AND clause:

(((o100539.PRODUCT_DESCRIPTION) = '1 Litre Blue Top'
AND o100539.PRODUCT_CODE = '10'))

Yes, now you can see the conundrum. No data is returned because there is no product called 1 Litre Blue Top in the database. Discoverer does not reassess the situation when an existing parameter is used. Is this a bug? Maybe. I will send this to Oracle for comment but I thought you would like to know.

I think the workaround would be to pick a new paramater value from the list, then go back and repick the original value. Assuming the worksheet now returns data the worksheet needs to be resaved. Of course, this also assumes that the user using the worksheet is the worksheet owner. If they are not the owner then the problem will persist until the owner can be notified.

As I say - an interesting conundrum!

Welcome to Rod West

2008-10-14T16:24:00.005-05:00

I am delighted to be able to let you know that Rod West, a prolific answerer of questions on the OTN Discoverer Forum, will be joining me as a co-author on this blog.

Rod has been using Oracle databases since 1985 and is principal consultant at Cabot Consulting in the United Kingdom. He specializes in Oracle Applications 11i / 12i as well as Oracle Discoverer. Rod can be contacted at rodwest@cabotconsulting.co.uk

Rod has also submitted two white papers, both of which are available for immediate download from my website by clicking here

The papers are as follows:

Scheduling through concurrent manager - this paper describes how Oracle Applications Concurrent Processing can be used to schedule Discoverer workbooks
Using VPD to secure Discoverer reports - this article uses a series of examples to demonstrate how VPD can be used to secure Discoverer reports. The examples have been written with Discoverer in mind but VPD is a database centric approach and so can be applied to any reporting tool

Cumulative Patch 2 for 10.1.2.3

2008-10-06T16:24:00.002-05:00

I am very pleased to announce that Oracle have released a second cumulative patch for Discoverer 10.1.2.3.

So far this has been released for the following platform:
Windows 32-bit

The following postings have been updated:

Useful Patch Numbers
Do not upgrade to Discoverer 10.1.2.3

Important Note: Neither the base 10.1.2.3 nor any of its cumulative patches are certified for use against E-Business Suite 11i or 12i, so please don't upgrade to 10.1.2.3 if you are using or intend to use Discoverer in Apps mode. 10.1.2.2 and all of its cumulative patches are certified so this is where you should be, at least for the time being.

Be careful installing cumulative patches

2008-09-16T14:59:00.002-05:00

I can't stress the importance of making sure you read all of the instructions in the readme files that come with the cumulative patches. For example, the readme for cumulative patch 8 on Windows has the following statement concerning OPatch:

2. It is always recommended to have the lastest 1.0.0.0.xx opatch version.
Minimum opatch version is 1.0.0.0.57
Opatch version can be checked following the below steps:
- set ORACLE_HOME=
- set OPatch in the PATH
- opatch version

However, the same readme for the Linux install has this statement:

2. It is always recommended to have the lastest 1.0.0.0.xx opatch version.
Minimum opatch version is 1.0.0.0.58
Opatch version can be checked following the below steps:
- set ORACLE_HOME=
- set OPatch in the PATH
- opatch version

Notice that the minimum OPatch versions are different. This is very important.

Warning: If you attempt to install CP8 on Linux using OPatch 1.0.0.0.57 the install will fail and you will get a message saying that the inventory could not be updated.

Unfortunately, by this point the cumulative patch code will already have deleted some required files and so now even your original Discoverer will not work. The solution is to install the correct version of OPatch and rerun the cumulative patch. It will now put the right, required files in place and Discoverer Plus will operate correctly.

The moral of the story is to read the installation notes carefully so that you don't get caught out.