Candid Kitty

Ragdoll Kitten: Playing In Clothes BasketSince you’ve all been introduced to Princess, I thought it time to post a few more pictures we’ve managed to snap of her over the last fortnight. No surprise, Princess loves to play – often at inopportune times. One of her favourties toys has been a little blue mouse made of rope, she can really dig her claws into it!

This evening whilst researching on the internet, Princess jumped onto the table like normal. This time, it was different; this time she saw the mouse cursor on the screen and thought it was the best thing since sliced bread. As I moved the mouse, she followed it intently over the screens. When I started to wiggle it a little in front of her, she started trying to touch and bite the screen – so cute!

As it turns out, our Princess isn’t very lady like – she flops and sprawls over everything and anything, makes for great little cuddles though. She is also an intrepid explorer, if there is anything in the house she can climb under, over, through or into – she had already been there.

Oracle RETURNING Clause

The Oracle RETURNING clause was implemented as part of the Oracle 10g release and is used to return information about the effected rows after issuing Data Manipulation Language (DML) statements. Prior to Oracle 10g, you would have needed to work around not having this feature, most likely by issuing additional statements to the database.

The RETURNING clause has a few restrictions:

  • it is only available for use on tables, materialised views, normal views based on a single table or an expression based on the previous three items
  • it is only valid on a single-set aggregate. A single set aggregate is DML which only effects a single row or using an aggregate function in the RETURNING statement (such as SUM).

The general syntax for the RETURNING clause is:

INSERT INTO <table> (c1, c2, .., cn) VALUES (v1, v2, .., vn) RETURNING <expression> INTO <variables>
UPDATE <table> SET (c1) = (v1), (c2) = (v2), (cn) = (vn) WHERE <condition> RETURNING <expression> INTO <variables>
DELETE FROM <table> WHERE <condition> RETURNING <expression> INTO <variables>

This feature is particularly useful when INSERTing into a table, where the Primary Key is sourced from a sequence and fetched via a TRIGGER. In the below example, the ID of the newly inserted row is assigned to pContactID using the RETURNING clause. This is an elegant solution as it means you don’t have to SELECT the NEXTVAL from the sequence and assign that value to the ContactID during INSERT simply so you can return the new primary key value.

PROCEDURE Ins
(pContactID     OUT Contacts.ContactID%TYPE,
 pFirstname     IN Contacts.Firstname%TYPE,
 pSurname       IN Contacts.Surname%TYPE)
IS
BEGIN
 INSERT INTO Contacts
 (fname, sname)
 VALUES
 (pFirstname, pSurname)
 RETURNING ContactID INTO pContactID;
END;

You could just as easily use it to return the information about a row deleted, such as:

PROCEDURE Del
(pContactID     IN Contacts.ContactID%TYPE,,
 pFirstname     OUT Contacts.Firstname%TYPE,
 pSurname       OUT Contacts.Surname%TYPE)
IS
BEGIN
 DELETE FROM Contacts
 WHERE ContactID = pContactID
 RETURNING fname, sname INTO pFirstname, pSurname;
END;

Since the RETURNING clause is for use with aggregates, an example illustrating its use is in order. The below example modifies pContactID salary by pPercentageChange and subsequently returns the updated total company salary expenditure.

PROCEDURE UpdateSalary
(pContactID        IN Contacts.ContactID%TYPE,
 pPercentageChange IN NUMBER,
 pGrossSalary      OUT NUMBER)
IS
BEGIN
 UPDATE Contacts
 SET salary = salary * pPercentageChange
 WHERE ContactID = pContactID
 RETURNING SUM(salary) INTO pGrossSalary;
END;

The Oracle RETURNING clause provides the PL/SQL developer with a lot of flexibility. The real benefits however, come from the simplified PL/SQL and clarity gained in the code. If you’ve got a lot of application code or PL/SQL which isn’t utilising the power available to you – it might be time to undertake a clean up in your project.

Poo Fairies

Today while joking around with my work colleagues, I mentioned what I thought was a well known phenomenon known as the poo fairies. I was taken aback when they burst out in laughter and asked me what it was all about.

A formal definition for the uninitiated:

Poo fairy (n):
The little fairy that enters your room at night, while you are sleeping and takes a shit in your mouth. This then causes you to wake up with what is commonly referred to as poo breath.

Usage:
“Gee, I think the poo fairies visited me last night.”
“My breath smells like poo fairies have had a party in my mouth.”

Now that you have the official definition, it is your mission to spread to good word of the poo fairies as far and wide as possible!

Hello Kitty

Ragdoll Kitten: 12 week old lilac bi-colourPrincess, meet the internet; internet meet Princess! Friday evening saw a new addition to our little family, a 12 week old Ragdoll kitten!

It is Claire’s birthday on the 11th of April and Lucy (Claire’s younger sister) wanted to give something to Claire she knew she would love to death. Claire and I are both big cat fans and over the last 5 years we’ve had two. Our first one Felix (luxurious short thick dark grey hair) was unfortunately hit by a car, while our second one Ebony (jet black Permese) is on a permanent holiday at my parents place in Chinchilla.

Lucy and I have been colluding about the purchase of a new kitten for the last 4-6 weeks. It was my job to quietly work out which breed of kitty Claire really wanted this time; we short listed the Burmese and Ragdoll. After some appropriately timed discussion, the Ragdoll won! I informed Lucy of the choice and she then went about finding breeders in south east Queensland to purchase them from. After chasing a few up, the Braveheart Ragdoll Cattery at Bundaberg got the nod.

The little bundle of fluff came with a swag of other goodies from Lucy as well:

  • a sleeping mat (like sheep skin)
  • very cute food containers
  • toys
  • kitty litter tray and litter
  • food

Needless to say, Claire and I are super excited to have another little kitty in our lives – they rock. A huge thank you to Lucy for organising the whole thing, you’ve made Claire and I extremely happy.

From now on, expect frequent, extra cute photos of Princess appearing on the site!

Oracle Data Provider (ODP.net): Data Provider Internal Error (-3000/-3001)

During a recent release of a new ASP.net website, the launch went horribly wrong and required a rollback.

Setup

Front of house Back of house
  • Windows 2003 Server Standard
  • IIS6
  • Microsoft .net 1.1
  • Oracle Data Provider v10.1.0.301
  • Redhat Linux Enterprise R4
  • Oracle 10g Enterprise Release 2, clustered using RAC

Scenario

Whilst the code was in the development environment, we weren’t seeing any issues. Once the code was published to a staging environment and the load on the temporary under powered server increased, we started to see errors creeping in. At the time, it was written off as being a combination of Oracle 10g Release 1 Standard and the server simply not having the resources to handle the load. We had previously seen poorly written legacy code bring a Dual 3.2Ghz Xeon running Oracle 10g Standard Release 1 (dedicated server processes) to its knees with similar style random errors.

Searching online seemed to reveal a common trend; it was an Oracle Data Provider problem. Unfortunately, everything we found was related to the version 9 data provider – while we were already running version 10. After four developers spending a few hours trying to resolve the error, a support request was logged with Oracle via MetaLink. Over the following three hours and a continuous stream of phone and email correspondence with Oracle, one of their technicians informed us of a patch set available for our current Oracle Data Provider.

Patch Information

Patch Number #4355425
Description Oracle ODP.NET Patchset 10.1.0.3.04
Product Oracle Data Provider for .NET
Release Oracle 10.1.0.3
Bugs Addressed
4228597 OracleDataAdapter returning incorrect schema information
4205389 ODP.net hangs with multiple WHEN clauses on CASE statement
4190650 Direct path INSERT doesn’t work via ODP.net
4066828 Unmanaged exceptions return -3000 error without further information
4028378 Need attributes/methods on OracleParameter/OracleCommand classes
4020081 ODP.net -3000 errors under high load
3937454 Calling cancel before command execution causes an error
3930596 Output bind variable initialized with blanks using ParameterDirection.OUTPUT
3897454 Aborting selecting thread fails with internal error -3000
3893458 ODP internal error -3000 in ExecuteReader() method

Out of list of bug fixes, two items should be highlighted:

  1. 4020081: As we were running short of servers during the development phase, we had Oracle 10g Release 1 Standard installed on a standard desktop machine with a single hard drive. Once the application was released to testing, the Linux ‘load’ on this machine was regularly breaking 15-20. As such, this could have been contributing to the Data Provider Internal Error.
  2. 3893458: The legacy version of this application had been running on the v10.1.0.301 of the Oracle Data Provider for nearly a year without any issues. That code base made very limited use of PL/SQL stored procedures, while all new code was being funneled through PL/SQL. Strangely, the legacy code would have been firing the ExecuteReader() method, while the new code was firing ExecuteNonQuery(). If this was the cause directly, you would have expected those to be around the other way. I think it is worth listing here, as the decision to funnel everything through PL/SQL is a fundamental shift in the application architecture.

It should be noted that without the help of the Oracle Technician, we would have never found this patch on MetaLink in a timely fashion; which I would consider a serious shortcoming of the site. However, after downloading and applying the patch manually, the random errors immediately vanished.

There was a lesson learned from this experience, the Oracle Data Provider was discounted as a likely problem early on because we were using a newer version of the provider than that of the error reports we were seeing. Looking back on it, we should have immediately upgraded the Oracle Data Provider to the latest public release, simply to rule out a bug in an older version.