I had this exact same situation recently during a data conversion process. I needed a way to insert all the good records into a table, and identify those that failed.

My initial approach was to place the inserts in a for loop, wrapping the insert statement in its own block. When an exception is raised, it will be recorded and control will pass to the encompassing block allowing the loop to continue:

For i in 1..pi_employee_data.last loop
  Begin
    Insert into new_employees values pi_employee_data(i);
  Exception
    When others then
      dbms_output.put_line('Insert data '||SQLERRM
                           ||' Employee#'||pi_employee_data(i).employee_id);
  End;

End loop;

commit;

Now, this is all well and good. But what if you want to stick to “best practice” and use bulk statements. I’d been making use of collections, so using a forall statement seemed a better approach. Problem being, you can’t wrap the insert statement into its own SQL block. This is where SQL%BULK_EXCEPTIONS comes in.

Note the addition of ‘save exceptions’ to the following forall statement. If any exceptions are encountered when inserting into the new_employees table, they will be saved to the SQL%BULK_EXCEPTIONS object. Only when the forall statement is finished will the exception handler be called. We’re then free to extract any data regarding the particular record that caused the exception.

function insert_data (pi_employee_data in employee_records)
  return varchar2 is

  l_no_errors number;
  dml_errors  exception;

  PRAGMA EXCEPTION_INIT(dml_errors, -24381);

begin

  forall i in 1..pi_employee_data.count save exceptions
      insert into new_employees values pi_employee_data(i);

  commit;

exception
    when dml_errors then
      l_no_errors := SQL%BULK_EXCEPTIONS.count;
      for i in 1 .. l_no_errors loop
        dbms_output.put_line('Bulk insert error: '||
           SQLERRM(-1 * SQL%BULK_EXCEPTIONS(i).ERROR_CODE)||
           ' Employee:'||
           pi_employee_data(SQL%BULK_EXCEPTIONS(i).ERROR_INDEX).employee_id);
      end loop;

    when others then
      dbms_output.put_line('Error:'||SQLERRM||
         ' '||dbms_utility.format_error_backtrace);

end;

As mentioned in a recent article by Tim Place, knowing the problem is one thing, knowing where to find the solution is the other. Using the Oracle documentation and having an idea which keywords to use when looking for a solution makes problems such as the above that much easier.

Conincidently, SQL%BULK_EXCEPTIONS also made an appearance in one of Steve Feuerstein’s talks at the recent InSync conference in Melbourne. As anyone who’s seen Steve before will know, collections and bulk operations should be two of the staples of any piece of PL/SQL code you write. Now with SQL%BULK_EXCEPTIONS, you’ll be able to use them much more effectively.

I have had many clients ask me whether they can create Pay Variation reports in Oracle Discoverer, and how much effort is involved. It is possible and it is quite easy once you know how.

To create Pay Variance reports in Oracle Discoverer you only need access to Discoverer Administrator, and either Discoverer Desktop or Discoverer Plus (this example will use Discoverer Desktop) and a basic knowledge of how the products work.

Pay Variance reports allow users to compare employees pay details over two different pay periods.  Not only will this allow easy reading for users but also allow the creation of calculations, conditional formatting and other Discoverer features that highlight the data users need to see.

The below image is what we will now create;

Setting up the new Folder

To create a Pay Variance report in Oracle Discoverer, the first thing we need to do is setup a new folder in Discoverer Administrator.

Most clients wanting to create a Pay Variance report will already have an existing Pay folder in their End User Layer (EUL) so we will start from this point.  The below image shows the current EUL in Discoverer Administrator with the Pay folder expanded.  Our aim is to duplicate the Pay folder and join it to itself.

Duplicate the Pay Folder

It is good practice to create a new business area when creating custom folders, so I have created a business area called “Human Resources – Custom”

Since we want to duplicate the Pay folder, we can simply copy it.  To do this right click on the original Pay folder and click “Copy”

Next, right click on the business area that you want to add the duplicate the folder into and choose “Paste”

Your new folder should now appear in the business area you chose.  Next, change the name of the folder to something a little more meaningful.  I tend to call these kind of folders, the name of the original folder (In this case “Pay”) with the words “Outer Join” after it.  This is because the next step is to create an outer join to the folder.

Joining the Folders

Now we will join the new folder to the original one.  Do this by clicking on the new folder and clicking;

Insert -> Join

Then choose the field you want to join your folders by, in this case Employee ID and click “OK” to go to the join wizard.

Step 1 – Choose as many fields as you like to join the two folders together.  The fields to join by are employee identification fields like Employee ID and Job ID.  Don’t join by fields like Pay Period, as the point of this report to compare different pay periods, not join by them.  Once you choose the fields to join by click “Next”.

*Note – The folder on the left hand side of the screen is known as “Master” and the folder on the right hand side of the screen is known as “Detail”, this needs to be known for Step 2.

Step 2 – When creating the join, it can be a good idea to create an outer join.

The difference between an outer join and a regular join is;

• A regular join means that there must be a record in both tables to join by. If a record exists in one table but not the other, neither record will be displayed in the chart
• An outer join means that when linking the folders together, a record must exist in the first folder, but does not need to exist in the second folder.  For example if an employee got paid in one period, but not in the second period, the employee will still exist in the Discoverer report, but the second folder’s fields will be left blank.

We will create an outer join in this example to show records from the “Pay” folder even if they don’t exist in the “Pay – Outer Join” folder.

The join appears under the fields.

Once the new folder has been created and joined in Discoverer Administrator we can create the Pay Variance report using Discoverer Desktop.

Continue to page 2 to read this step …

Have you ever had your system show the wrong time, scheduled jobs in Alesco or Oracle not run when they’re meant to, or seen conflicting reports of what the current time is in different applications on the one system?

Well, I did recently while administering one of our client’s Alesco environments. The trace outputs for their Alesco reports were showing conflicting runtimes. Surprise, surprise there was an hour difference, and daylight savings was to blame.

Off the top of my head, there were only two places the times could be incorrect:

• on the database, and
• on the application server

So, I logged in and checked the database time. All good on that front.
Next, I logged into the application server and checked the system time. That was correct as well.

It seemed that my assumption was incorrect, there was a third place the time could be incorrect, in the Oracle Application Server software. A quick visit to the Oracle Application Server Control Console confirmed this. It turns out the Oracle Application Server software doesn’t use the underlying system’s timezone settings.

Metalink, the Oracle forums and Google were the next ports of call. After a lot of digging (the majority of timezone information I came across dealt with Oracle Databases, not Oracle Application Servers), I discovered that the problem was not specifically with Oracle. Both the Oracle Application Server Control Console and the Oracle Reports Server are Java apps, and it was the Java Runtimes they were using that were causing the timezone issue.

Java (along with Unix/Linux) measures time in milliseconds from January 1st 1970. Once this number has been converted into a human readable time, the timezone adjustments are applied. In Unix/Linux, these timezone settings can be found under /usr/share/zoneinfo (or /usr/share/lib/zoneinfo on some systems). However Java won’t use this system timezone database, it uses it’s own.

Inside your Oracle home, there are a number of java executables. Executing java -version told me I was on 1.4.2_12. A quick comparison with the Java Timezone Data Versions showed this release did not include the Australian 2008 timezone changes. Luckily Sun provides the Timezone Updater Tool to bring us up to speed.

Once you’ve downloaded and unzipped the tool, you can update a single JRE/JDK with the following command:

> java -jar tupdater.jar -U -v

This assumes the java executable is in the home you want to update (type which java to check)

As I said, there’s multiple JRE/JDK homes in the Oracle Application Server homes, so why not update them all at the one time:

> /usr/bin/find DIRPATH -fstype nfs -prune -o -fstype autofs -prune
-o -name java -print -exec {} -jar /ABSOLUTEPATH/tzupdater.jar -u \;

Then it was just a matter of bouncing the Oracle processes again.

Ta-da, the times are now correct.

Note
I did receive a number of warnings when updating the timezone. It turns out they were Solaris specific and could be ignored, eg:

Q.
I get the following message after running the TZ Updater Tool v1.1.0 on Solaris, what does it mean?

/jre/bin/java not directly found in contents file, no package resolution performed.
(May not be in PKG form, not an absolute path, or is a symlink.)

A.
This message indicates that the JDK/JRE software just updated was not part of a Solaris package. No step was necessary to update the OS with the fact that files under package management have changed, that is, jre/lib/zi directory contents. The update of the timezone data has been successful in this case.

Discoverer reports can take take a long time to run. To run the report manually and then wait for the report to finish can sometimes be a timely and frustrating exercise.

An easier way to get the reports you want without the long wait is to schedule them.

Discoverer offers functionality to schedule reports and to simply open the result at a later time. But there are are a few steps to take to do this.

Getting the Right Permissions

The user wanting to schedule reports needs to have access to the table v_$parameter.


SQL> CONNECT /@ AS SYSDBA;
SQL> grant SELECT on v_$parameter to [Username];


Scheduling the Report

To schedule a report you must first save a report to be scheduled, from this point I will assume you have a report you want scheduled

• Go to File > Manage Workbooks > Scheduling Manager

• Click Schedule
• Choose Database or My Computer depending on where the report is saved and click Schedule

• Choose a workbook to run and click Schedule

• Choose the worksheet(s) to run, the time and date to run and whether to repeat the refresh and click Next

• Give the task a unique name and description and click finish. (If the name is not unique you will be prompted to let discoverer name it for you, generally adds a 1 to the end.)

• The Workbook will be visible on the main Scheduling Manager screen

Retrieving the Output

Once the report has been run

• Go to File > Manage Workbooks > Scheduling Manager
• Click the the already run scheduled task

• Click Open
• Asked whether to open the results, click Yes and you will see the report

Conclusion

So now if you need to run a long report, save yourself some time: schedule it to run over night and simply collect it in the morning.

You could search through an find the object definitions in your source code, then cut and paste to recreate the objects in the correct order. But why not make Oracle work for you and use the DBMS_METADATA package generate the object definitions for you dynamically!

The DBMS_METADATA package allows you to extract the DDL required to recreate any object (tables, triggers, indexes etc) in the database that you have access to.

So, should we wish to extract the DDL required to generate the indexes on the EMPLOYEES table in the Oracle XE Database HR schema, we can run the following PL/SQL:

set serveroutput on size 100000

declare
  handle number;
  tranform_handle   number;
  object_definition clob;
begin
  -- Define the object type we're exporting
  handle := dbms_metadata.open(upper('INDEX'));

  -- only get the objects for the current table
  dbms_metadata.set_filter(handle, 'BASE_OBJECT_NAME', 'EMPLOYEES');

  -- add the trailing semicolon to the output
  tranform_handle := dbms_metadata.add_transform(handle, 'DDL');
  dbms_metadata.set_transform_param(tranform_handle, 'SQLTERMINATOR', TRUE);

  -- extract all the object of type  for the given table
  loop

    object_definition := dbms_metadata.fetch_clob(handle);

    exit when object_definition is null;

    --convert the clob to a string
    dbms_output.put_line(dbms_lob.substr(object_definition, 32000, 1));

  end loop;

end;

Obviously in a real life example you wouldn’t sent the output to the screen, but this simple example shows another of the useful built in packages provided by Oracle.

For more information on the DBMS_METADATA package, see the Oracle online reference guide.

On investigation, we found the report was showing inconsistent data due to the Discoverer Query Governor Option “Limit retrieved query data to” set to 10,000 rows.

When the report was run, a warning appeared stating that “Not all rows have been retrieved. Data may be inaccurate”.

We asked the user to un-check this option for the workbook, and the problem was solved.  The report now returns the correct values consistently.

This story is a good example of how easy it is for the business to lose faith in reports due to a relatively minor issue – in this case a simple option setting in Discoverer.

Remember, if in doubt with any technical solution, just ask. It could be that a very simple tweak like this will have you up and running again.

Instant Client also comes with a command line SQL*Plus utility.

Instant Client was released in Oracle 10g but can be used to connect to older Oracle databases to 8.1.7. Instant Client is a free, production ready Oracle tool.

Download Instant Client

Instant Client can be downloaded free from Oracle’s OTN website, you’ll need the:

• Instant Client Package – Basic (32mb)
• Instant Client Package – ODBC (700k)
• Instant Client Package – SQL*Plus (260k) (if you want to use SQL*Plus)

These files come in a winzip format.

Installing Instant Client

Extract the zip file to a directory where you want the Instant Client program to live (say C:\Program Files\Instant Client).

Run the file odbc_install.bat – this updates some registry settings for the ODBC install

Update your PATH environment variable to include the Instant Client directory.

To do this, go to Control Panel, System and click on the Advanced tab.

Click on the Environment variables button and edit the ‘Path’ variable to add the Instant Client directory path (C:\Program Files\Instant Client). Make sure you don’t mess up your other settings in the Path.

The Oracle ODBC drivers have now been installed! Easy.

Set up a tnsnames.ora (optional)

The tnsnames.ora file is a config file used by Oracle software that specifies the connection details of the databases you want to connect to.

If you don’t use a tnsnames.ora file, you’ll need to specify the connection details (server name, port number, database name) every time you connect to the database instead of just specifying the alias name.

To create a tnsnames.ora file create a text file and add:

alien =
  (DESCRIPTION =
    (ADDRESS_LIST =
        (ADDRESS =
          (COMMUNITY = tcp.world)
          (PROTOCOL = TCP)
          (Host = 192.168.0.100)
          (Port = 1521)
        )
    )
    (CONNECT_DATA = (SID = alien)
    )
  )

Place this file in the Instant Client directory.

Now add a new environment variable TNS_ADMIN (like the Path variable) to tell Instant Client where to look for the file.

Note: If you already have other Oracle software installed on your PC, chances are you have a tnsnames.ora. To use that file add a new environment variable TNS_ADMIN and point this to the location of your existing tnsnames.ora

Configure the ODBC connection

Set up the ODBC connection by going to Control Panel, Administrative Tools, Data Sources (ODBC). Click on the System DSN tab and click Add.

Note: If you only want your Windows login user to see the data source, use the User DSN tab.

If prompted for a driver to use, select the ‘Oracle in instantclient’.

Enter a name and description for the data source, if you are using a tnsnames.ora file the database alias should be available in the TNS Service Name drop down list. Otherwise leave this field blank.

Leave the other settings to default unless required, although if you’re only viewing data it may be wise to check the “Read-Only Connection” checkbox.

Test the Connection

On the ODBC Driver Configuration page (shown above), click the ‘Test Connection’ button. This will bring up the connection screen.

If your TNSNAMES.ora has been set up simply enter your details:

Service name: database alias name
Enter user-name: username
Enter password: password

If you haven’t set up your TNSNAMES.ora the service name will be in the format: servername:port/sid

Where server name is the ip or name of the server running the Oracle database, port is the port number the Oracle listener is running on and sid is the sid name of the database.

For example 192.168.0.50:1521/mydb

If all is good you should get the ‘Test Sucessful’ message returned to you.

Trouble Shooting

System error code 998 – malformed or spaces in the PATH env variable

For more configuration help see the Instant Client Forums.

Connecting to SQL*Plus

To run SQL*Plus, go to the directory where Instant Client Package – SQL*Plus was unzipped and run the application sqlplus.exe. This will bring up the following screen where you will connect to the database.