Thursday, October 23, 2008

Row Generators

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 ValuesCalculationCondition
Days of the weekTO_CHAR(TRUNC(SYSDATE, 'D')+n-1, 'Day')N<=7
Previous 12 monthsADD_MONTHS(TRUNC(SYSDATE, 'MONTH'),
1-n)
N<=12
Letters of the alphabetCHR(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.

Tuesday, October 21, 2008

Pictures of Darlene and Michael

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:



















Thursday, October 16, 2008

Interesting condrum with indexed values

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!

Tuesday, October 14, 2008

Welcome to Rod West

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

Monday, October 06, 2008

Cumulative Patch 2 for 10.1.2.3

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.

Tuesday, September 16, 2008

Be careful installing cumulative patches

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.

Friday, September 05, 2008

Revised Apps mode white paper

As many of you already know I am the author of several white papers on Discoverer.

I am pleased to be able to let you know that I have today publised a fully revised version of the popular Setting up an Apps mode EUL.

You will find it on my downloads page.

It has the following 5 sections:
  1. Installing the Admin software
  2. Setting up Discoverer to work with E-Business Suite
  3. Patching Discoverer Admin to the correct level
  4. Creating an E-Business Suite End User Layer
  5. Setting up E-Business Suite privileges

Wednesday, August 27, 2008

Cumulative Patch 8 addendum

A few days ago on 15th August Oracle released a second edition of CP8. This edition, using patch number 7306816, is only for the following 3 platforms:
  • Linux x86
  • Sun Solaris SPARC 32-bit (which is also good for 64-bit)
  • HP-UX PA-RISC 64-bit

The reason for the updated patch is to fix some additional bugs specific to these platforms, namely:

BUG 6742626 - DISCOVERER DISCONNECT IF WE DRILL TO RELATED TO THE SAME ITEM TWICE
BUG 6933011 - 'AN ERROR OCCURRED WHILE ATTEMPTING TO PERFORM THE OPERATION' WHILE OPENING REPO
BUG 6686944 - FONT SIZE TOO SMALL EVEN IF ADJUSTPLUSFONTSIZE = "TRUE" AND ZOOM SET

If you are using Solaris and have already applied the initial patch then you should be fine, but since 7306816 has three more patch fixes, then this will be the one recommended by Oracle Support going forward if it is available for a specific platform. Personally, if I was on Solaris, I would apply 7306816 even if I had already applied the original 7111816. I like to have the latest fixes where possible.

As I say, it is currently released on Solaris, Linux and HP-UX.

The Windows platform will continue to use 7111816

See also:

My Original CP8 posting

My posting concerning patch numbers

By the way, if you are using E-Business Suite 11i or 12i then all of the cumulative patches for Discoverer 10.1.2.2 are certified for use. You do not need to wait for further confirmation by Oracle as this is part of the patch release testing.

However, neither Discoverer 10.1.2.3 nor its recently released CP1 are certified for use with E-Business Suite so do not upgrade to 10.1.2.3 at this time. 10.1.2.3 is a non-reversible upgrade so don't go there if you are using E-Business Suite. You have been warned!

Friday, August 15, 2008

Cumulative Patch 1 for 10.1.2.3

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

So far this has been released for the following 3 platforms:


  • Windows 32-bit
  • Linux x86
  • Sun Solaris SPARC (32-bit) - which means 64-bit as well

The following postings have been updated:

Important Note: Neither 10.1.2.3 or CP1 is 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.

Wednesday, July 30, 2008

Cumulative Patch 8

Posting updated: August 27, 2008

Oracle have recently released CP8 for Discoverer. The patch number for Windows is 7111816. The patch number for Linux, Unix and HP is 7306816. While 711816 was also released for Unix, this has subsequently been re-released with further improvements as 7306816. If you are running on Unix and have already applied 7111816 you should also apply 7306816. This will de-install the previous CP8 and install the latest version complete with additional bug fixes.

My blog posting relating to patch numbers has been updated to reflect this new cumulative patch.

For more information about patches for Discoverer click here.

At the moment CP8 is available for these platforms:
  1. Microsoft Windows 32-bit - using 7111816
  2. Sun Solaris SPARC 32-bit (which is also good for 64-bit) - using 7306816
  3. Linux x86 - using 7306816
  4. HP-UX PA-RISC 64-bit - again using 7306816

Some welcome fixes:

Welcome fix 1

Looking through the readme it seems as though Oracle may have fixed the CP7 issue that I reported a couple of weeks ago. I have tested this out on my own system and the list of values now populate with no problem.

Welcome fix 2

Another bug, this time one that has irritated end users for some time, has been fixed in this patch. Prior to this patch, if someone shared a workbook with you and you tried to Save As using the same name you would get an error that the workbook identifer must be unique. You would then be forced to save the workbook under a different name which was most inconvenient. I am very pleased to report that has been fixed in CP8.

Let's say that someone shares a workbook with you called Sharing Test.

Under the new functionality, if you use Save As and leave the workbook name the same, Discoverer will automatically assign a unique identifer to the workbook. What it does is to append the number 1 to the end of the identifier. Thus, in my example, the identifier for this workbook will become SHARING_TEST1. I know this fix will be welcome news to hundreds of users.

Good one Oracle - 10 out of 10 from me for this fix.

Welcome Fix 3

One other "fix" that may be welcome to you in CP8 is that changing Page Items in Discoverer Plus cross-tabular worksheets and scrolling has been incrementally improved. I'm not sure if you have ever noticed this as it generally only rears its ugly head when working with more complex type worksheets. Performance is still not "Desktop" speed due to the architecture differences, but it is much improved. The generic scroll properties that were introduced in CP2, I think, may no longer needed. If you have been having issues with those sort of "performance" issues, then you might want to give CP8 a try.

The particular bug fixes that I am referring to in CP8 are as follows (this information is taken from the CP8 readme):

328) Bug 7166233 - WITH SOME SCROLL PREFERENCES, TABULAR WORKBOOKS WILL LOCKUP WHEN SCROLLING

329) Bug 6938007 - CHANGING PAGE ITEMS IN PLUS RENDERS THE PAGE VERY SLOWLY

Wednesday, July 16, 2008

Speaking in Oklahoma in July

If you happen to be in Oklahoma City on Tuesday, July 22nd I will be presenting a paper on manipulating dates in Discoverer at the Oklahoma City Oracle User Group meeting.

This will be at the Francis Tuttle Institute of Technology, Rockwell Campus, in Oklahoma City on 12777 N. Rockwell Ave at 5:15pm

For more information please look on the OKCOUG website

I'll see you there

Monday, June 16, 2008

Discoverer polls 1 and 2

So that I can provide a better service to the industry, from time to time I will be conducting polls of the Discoverer commulity on various topics.

The results from the first 2 polls can be seen in the panel to the right. As you can see they make very interesting reading.

Thursday, June 12, 2008

Monitoring and removing old statistics

This is a posting for Discoverer administrators.

As you may know, there is a switch on the Privileges screen called Collect Query Statistics.

Most organizations leave this turned on. When it is turned on, every time an end user logs in and runs a worksheet, statistics about that run are collected into the table called EUL5_QPP_STATISTICS. Thus, there will be one row in the statistics tables for every execution of every worksheet in every workbook. Even if an end user creates only an ad-hoc query and doesn't save it to the database the statistics will still be captured.

If your organization has lots of users executing lots of worksheets every day you can imagine that this table will get quite large. Another thing that happens is that over time the extents on the indexes, of which there are 3, grow rapidly to many thousands. What this means is that performance is going downhill.

Here are the 3 indexes:

  • EUL5_QS1_I
  • EUL5_QS2_I
  • EUL5_QS_PK

You therefore want to consider purging your statistics from time to time. Many organizations that I have worked with like to keep at least the last six months of statistics, although some only keep 90 days.

What you may not be aware of is the fact that Oracle supply a SQL script that can check the statistics and, optionally, delete those which are over a number of days old. The script also provides a report on how many entries there are in the table, in buckets of 10 day increments, like this:

You can find the script here on your Admin machine:
[ORACLE_HOME]\discoverer\util

It is called: EULSTDEL.SQL

To run the script, use this workflow:
  1. Log in to SQL Plus as the owner of the EUL
  2. Type this @c:\oracle\bitoolshome_1\discoverer\util\eulstdel.sql and press Enter
  3. You will be prompted to enter a parameter. This parameter is the number of days of statistics you want to keep. If you want to keep all of your statistics, enter a large number or just run the SQL at the end of this posting. If you enter 0 the script will delete all of your statistics because it actually deletes rows which have a created date less than SYSDATE minus this number. Therefore, be careful!
  4. The SQL will run and produce the report, optionally deleting your old statistics

Note: in step 2 of the above workflow I have included the most-commonly user location for the Discoverer Admin tool. If yours is not in this location you will need to change this line.

Having deleted the statistics, you will more than likely want to ask your friendly DBA to rebuild the 3 indexes listed above, and again below. I have seen terrific improvements in performance when this has been done.

  • EUL5_QS1_I
  • EUL5_QS2_I
  • EUL5_QS_PK
By the way, if you just want to see your statistics, here is the SQL:

SELECT
TRUNC(SYSDATE-QS_CREATED_DATE,-1) Days_Old,
COUNT(*) No_of_stats
FROM EUL5_QPP_STATS
GROUP BY TRUNC(SYSDATE-QS_CREATED_DATE,-1)
ORDER BY 1 DESC

How many users

From time to time I am asked to provide scripts that help administrators manage their Discoverer system. One such example is below.

I was asked if I knew of a way for a company to know how many users they had using Discoverer so that they can make sure they are compliant with their licensing. The following script will do just that, plus a little more:

SELECT DISTINCT
UPPER(QS.QS_DOC_OWNER) USERNAME,
COUNT(QS_ID)REPORTS_RUN,
MAX(QS.QS_CREATED_DATE) LAST_USED,
MIN(QS.QS_CREATED_DATE) FIRST_USED
FROM EUL5_QPP_STATS QS
WHERE QS.QS_CREATED_DATE > '01-JAN-2006' AND
QS_DOC_OWNER IS NOT NULL
GROUP BY UPPER(QS.QS_DOC_OWNER)
ORDER BY 1;

Note: there is a restriction to running this script in that it will only tell you about users who have their own workbooks and when they were last ran. If you are using Discoverer connections you will not be able to use these scripts because the workbook will not necessarily be owned by the user who owns the connection or, if using SSO, by the user who is logged in. I am still researching if there is a way to derive this information.

The date parameter is there to check users who have been on the system from that date. This way you can exclude reports that were run a long time ago. You can drop it altogether if you like. If you do this you will see the total number of users you have had running reports. Of course, this assumes that you are collecting query statistics and that you haven't purged them - which will be the subject of another posting.

The report will tell you who has run a report in Discoverer, how many reports the user has executed, when the user first logged in and when the user last logged in to run a report. Using this information you can determine how many licenses you need or just to see who are the most frequent Discoverer users on your system.

To accomplish the latter just add another clause. Let's say you only want to see users who have run at least 25 reports. All you need to do is this:

SELECT DISTINCT
UPPER(QS.QS_DOC_OWNER) USERNAME,
COUNT(QS_ID)REPORTS_RUN,
MAX(QS.QS_CREATED_DATE) LAST_USED,
MIN(QS.QS_CREATED_DATE) FIRST_USED
FROM
EUL5_QPP_STATS QS
WHERE

QS.QS_CREATED_DATE > '01-JAN-2006' AND
QS.QS_DOC_OWNER IS NOT NULL

GROUP BY UPPER(QS.QS_DOC_OWNER)
HAVING COUNT(QS_ID) >= 25
ORDER BY 1;

Finally, let's say you want to extend the SQL again to include only users who have run a report within the last month yet still include users who have run at least 25 reports since 2006. This dynamic script will do that:

SELECT DISTINCT
UPPER(QS.QS_DOC_OWNER) USERNAME,
COUNT(QS_ID)REPORTS_RUN,
MAX(QS.QS_CREATED_DATE) LAST_USED,
MIN(QS.QS_CREATED_DATE) FIRST_USED
FROM EUL5_QPP_STATS QS
WHERE
QS.QS_CREATED_DATE > '01-JAN-2006' AND
QS_DOC_OWNER IS NOT NULL
GROUP BY UPPER(QS.QS_DOC_OWNER)
HAVING

COUNT(QS_ID) >= 25 AND
MAX(QS.QS_CREATED_DATE) >= TRUNC(SYSDATE,'MM')
ORDER BY 1;

Tuesday, June 10, 2008

LOVs in Plus following upgrade to CP7

Update posted on 30th July 2008:
CP8, which was issued on 11th July 2008 has fixed this issue from CP7. Therefore if you have installed CP7 and CP8 or higher is available for your platform you should apply the most recent patch that you can. The CP8 patch, by the way, is 7111816. If you have not installed CP7 you should install CP8 or the most recent cumulative patch instead. Click here for more information regarding the patches you can install.

I hope you have been following along with my postings concerning staying up to date with cumulative patches. Following the application of CP7 you may find that your users complain that lists of values no longer expand in Discoverer Plus when they click the little plus key alongside an item in the Available Items pane.

A new preference setting controls the number of items that can be displayed. The new setting appears to be defaulting to 0, thus preventing any items from displaying in the list of values. If you have access to MetaLink take a look at document 601996.1. This is the readme for CP7 (patch 6778560). Scroll down to Special Instruction 17. It appears to indicate that the preference is only needed if you have more than 1000 items in the list of values.

I have found this not to be the case and that, certainly for all the Discoverer servers that I have upgraded, the preference always needs to be set, even if there are less than 1000 items in any of my lists of values.

If you are experiencing a loss of the list of values, to rememy this, do the following:

  1. If Discoverer Plus is running, exit from Plus
  2. If Discoverer middle tier OPMN is running, it needs to be stopped as follows:
    a. Launch cmd window in Windows or connect to Unix / Linux as ORACLE user
    b. Navigate to $ORACLE_HOME\opmn\bin
    c. Type opmnctl stopall and press Enter
    d. Leave this window open
  3. Navigate to $ORACLE_HOME\discoverer\util
    In Windows: ORACLE_HOME will usually be C:\Oracle\BIHome1
  4. Edit the file called pref.txt – it may just be called pref if you are doing this inside Windows Explorer
  5. Add the following 2 lines to the bottom of the file (use copy and paste):

    [Generic Properties]
    genericLovSizeSoftLimit = 100 # items allowed in LOV

    Note: if you already have a Generic Properties section that was added for the inclusion of a previous bug fix you should add the new preference in that section. Most installations will not have this section so adding it to the bottom of the list of preferences is the logical place.

  6. Save the file
  7. Still in $ORACLE_HOME\discoverer\util: execute the file called applypreferences (it will be called applypreferences.bat in Windows and applypreferences.sh in Unix / Linux)
  8. Navigate back to $ORACLE_HOME\opmn\bin
  9. Type opmnctl startall and press Enter

Discoverer Plus should now display your lists of values.

Note: The preference and value of 100 we just set allows up to 100 items to appear in a LOV. You need to alter this value if your site has lists of values that have more than 100 items. The whole point of this new preference is to remove the restriction of 1000 items like there used to be in previous versions of Discoverer.

Monday, May 19, 2008

Using CASE to solve Outer Join issues

As many of you know, one of the services that my company offers is Discoverer workshops. What this means is that we send one of our experienced trainers on site and work, sometimes one on one, with the end users on their real system to help them generate the reports that they need. Sometimes I get to go and while I would like to do this more often I just don't have enough time so when the chance does come around I jump at it.

Anyway, one of the most frequent problems that I come across with end user reports is how to effectively create and work with reports when two or more of the folders have outer joins. Such a situation happened in one of the recent workshops that I conducted.

Picture if you will an EUL with 2 folders, folder A and folder B, where folder A is the master being outer joined to B. Thus, if you include something from both folders you will get one row for every item in folder A even if there is nothing in folder B. This is the benefit of the outer join.

Let me get more specific. Let's say that we are working in Human Resources where folder A is Employee Master and folder B is for Employee Leave. Because not all employees have taken leave there is an outer join between the two. Now let's say that in the Leave folder there is an item called Leave Desc that contains descriptions to indicate what kind of leave the employee had taken. With me so far? Here's a screenshot:




Here's some example output:


Ok, so now we want to build a report that allows the end user to exclude one or more Leave Desciptions from the report. To be specific, We want to see all Employees who either have not been sick or have not taken any leave yet. Looking at the report we should be including Carol, Michael and Susie, but not George.

Simply creating the following condition will not work:

Leave Desc <> 'Sick'

Here is that output:


As you can see, George is still included but now appears to have not taken any leave, which isn't true. How about if we also say that Leave Desc IS NOT NULL?

This doesn't give us the right answer either because now both George and Carol have been omitted.

Let's create this calculation which we will call Exclusion:

CASE WHEN "Leave Desc" = 'Sick' THEN 1 ELSE 0 END

We now get this answer, which as you can see has annotated the rows we do not want with 1.



You might think that adding this condition: Exclusion <> 1 would work but it will not. Try it for yourself and you will see what I mean.

You actually need to do add a Boolean OR condition, like this:

Exclusion <> 1
OR
Exclusion <> 1



Problem solved - isn't it? Try removing the Exclusion from the report and see what happens. In Plus you will get the right answer. However in Desktop you will find that your sorting goes wrong. The solution in Desktop is to add a hidden group sort on the Exclusion!

The problem is solved because of the way the CASE statement works which dictates that the function will end as soon as a true condition is encountered. So even there are NULL records these will all get Exclusion of 0 which is the default.

Friday, May 16, 2008

How to find Discoverer patches

A few people have contacted me recently saying they were having troubles finding the latest Discoverer patches. To help you, here is a workflow:

  1. Launch Metalink and enter your login ID and password
  2. Click the Patches & Updates tab
  3. Click the Simple Search link
  4. Change Search By from Patch Number/Name to Product or Family
  5. Enter Oracle Discoverer Family in the search box
  6. Change Release to iAS 10.1.2.2
  7. Set both Patch Type and Classification to Any
  8. Select your operating system or use Microsoft Windows (32-bit)
  9. Click the Go button
  10. The patches will be listed in order of release with the most recent first

Wednesday, May 07, 2008

Discoverer 10.1.2.3 update

August 2008 Important Update: Oracle released CP1 for Discoverer 10.1.2.3 on August 7th (link to patches)

In a recent posting of mine (link) I advised you not to upgrade to Discoverer 10.1.2.3 just yet.

I have heard that Oracle is working on a critical patch update for 10.1.2.3 that will incorporate all of the 10.1.2.2 critical patches (CP4, CP5 and CP6) plus fix any specific 10.1.2.3 issues that are unique to that release. The latest information I have is that you should expect to see the 10.1.2.3 patch before the end of the summer. I don't have any better timeline than this I'm afraid. As soon as I hear something more definite I promise I will let you know.

Therefore, for the time being I still recommend not upgrading to 10.1.2.3. You should, however, upgrade to 10.1.2.2 and apply the most recent critical patch (link).

Wednesday, April 30, 2008

BI Publisher and Discoverer - 1

Well it took me a while and lots of digging but I finally managed to get BI Publisher and Discoverer to interface to each other. If you are one of the hundreds who have tried and been unsuccessful, or maybe got there in the end you will understand what kind of an achievement this is.

I made lots of notes as I did the installation(s) and am now formulating a plan of action for publishing a series of articles that will describe in detail exactly how to go about taking a 10.1.2.2 Discoverer and making it interface with BI Pubisher.

Watch this space in the coming weeks.

Thursday, April 24, 2008

Performance degradation between IE and McAfee

It has recently come to my knowledge, via Mike McGrath, that there is a serious degradation in performance if you use Discoverer in the MS IE6 or IE7 browsers when you have the McAfee ScriptScan protection enabled. I know this will come as a shock to many corporate organizations but it is true nevertheless. It is known to affect McAfee 8 and 8.5 but may well be happening with other versions and be the cause of so many people complaining about Discoverer and / or Portal performance.

Note: the above applies equally to Discoverer Viewer and Oracle Portal and probably many other Oracle tools

What appears to be happening is that McAfee is checking the data being returned from Discoverer before allowing it to be displayed on the screen. If you have McAfee and are using either IE6 or IE7 you may be complaining to your IT department about the slow running of Discoverer. This is not a Discoverer issue. We can prove this by running the same report in Firefox where it will run fast.

If you are observant, you can tell that something is amiss because the browser itself will indicate that it has finished processing (the green status bar at the bottom right will be removed or the Windows icon at the top right will stop wiggling around), yet the output still does not display and may not do so for 10 or more seconds.

As a background to all of this, IE uses a Windows component called Windows Scripting Host, or WSH for short, to execute JavaScript (and other things). My version of WSH was 5.6. The most recent version is 5.7, though Microsoft claim that there are no major changes in 5.7! However, one of the changes that they do mention is an improvement to JavaScript that should benefit pages with lots of AJAX-like features (like our Discoverer and Portal pages).

Here is the link to download WSH 5.7:

http://www.microsoft.com/downloads/details.aspx?FamilyID=47809025-D896-482E-A0D6-524E7E844D81&displaylang=en

I installed WSH 5.7, and while this did help IE7 it had no impact on IE6. We therefore seem to have the the following four options:
  1. Do not use McAfee - probably not an option for many users if the corporate policy is to use McAfee
  2. Disable the ScriptScan feature of McAfee across the enterprise - there may well be some resistance to this from your IT department
  3. Do not use IE6 but use Firefox
  4. Upgrade to IE7 and upgrade to WSH 5.7

I guess there is a fifth option which would be to get McAfee to include an option whereby you could specifiy which domains you trust data to come from and therefore bypass the scanning process.

Options 1, 3 and 4 are relatively simple to do although not simple to apply enterprise wide. I will therefore now concentrate on option 2 and show you how to disable the ScriptScan feature inside McAfee.

  1. First of all, right-click on the McAfee icon in the taskbar. You will see the following pop-up
  2. From the pop-up, select On-Access Scan Properties. The following dialog box will be displayed.
  3. Click on the ScriptScan tab
  4. Uncheck the box called Enable ScriptScan
  5. Click the Apply or OK buttons

I found that disabling ScriptScan usually takes effect immediately and you can even stay within the browser. You should see an immediate improvement in Discoverer performance.

When I tried re-enabling ScriptScan, to prove that McAfee was indeed the culprit, we noticed that we had to close the browser, and therefore the Discoverer session, before scanning was implemented again.

I found another interesting article on Andy Dominey's Blog concering this issue. You may want to take a look (link)

Note: as previously mentioned, the above applies equally to Discoverer Viewer and Oracle Portal and probably many other Oracle tools

If you have a solution for this or know of another workaround please let me know (email)

Followers