By Tim Dexter on Jan 14, 2008
This is one for those of you bursting with the standalone release - for the rest of you, I'll try to make it interesting.
I have to admit I was not going to blog today, too much other stuff on that needed my attention. The ever present Oracle Messenger window on my laptop has been blinking most of the day with questions and comments. I guess I chose for it to be ever present but working remote you need to try and be available through all channels. Klaus (DevMgr) will disagree here as we can never find the right moment to share a 'catch up phone call'.
One of the blinking windows caught my eye, Kevin, from our support organization had a question on our internal mailing list and was pinging me for a followup. Kevin, like Pieter, in my opinion is worth his weight in gold - those of you that made it to the demo booth at OOW07 and found Kevin, I hoped pumped him for as much information as possible. He is a proverbial gold mine of all things XMLP/BIP - the guy remembers specific patch numbers for heavens sake. These maybe burned into his brain because its our fault for some stoopid bug and every one of you logging SRs has hit the same problem. Nevertheless, if you happen to meet or interact with Kevin in an SR, once more you have hit gold. I could not think of another word for 'pay dirt'- that's reserved for Pieter. I dont think its really a 'UK' english expression and I could not think of an equivalent ... moving on.
So, Kevin was getting a null pointer exception with his bursting run - no matter what he did. One of those great error messages we sometimes dump.
Caused by: java.lang.NullPointerException
A bit of digging around on his system and a neat trick to get a look at the burst sql result and I found the problem. First the trick - once you have your bursting sql or even want to test it while developing. Just create a new Data Model and paste in your bursting sql
Now you have the main sql and the bursting sql - just get a Concatenated Data Source
When you run the report (not in Bursting mode) you'll get the bursting sql result too.
This is how I found the issue, Kevin's result set had an anomaly.
Notice we have null values for the KEY element - we cant handle that - and I dont think we should do. I'll accept we should fall over more gracefully but how should we handle the null values for the KEY value to match on? Thats up to you to handle - I got around it with an NVL value to avoid the null KEY value and thus the falling over.
select nvl(NOMINEE,'Kevin McDermott') KEY,
Now back to work ...