Oracle Reports Migration Gotcha!
By Tim Dexter-Oracle on Apr 30, 2009
In recent weeks I have been working with several customers on the migration utility. As those that have used will know, its not perfect by any means. But it does get you down the path of migration a fair way.
I spent half an hour scratch my hairless head (Ive run out of hair to pull out so resort to scratching now :) this morning. It was over a variable population error, the value was too large for the variable e.g. squeezing 'Larkspur' into a varchar(2) will not go! What was meant to happen was a code e.g. LK was supposed to go into the variable.
As you may know, BIP supports LOVs for parameters, you have the option of showing a user value but passing a code to the query. It seems that Oracle Reports works things the other way round i.e. pass the first and show the second ... grrrrr!
A quick look see at Oracle Reports reveals that yep, they use code, user_value whereas BIP uses user_vale, code ... dang!
A look at the XML rendition of the LOV shows that we might be able to get the converter to be a little more intelligent.
<![CDATA[select last_name, employee_id from employees]]>
If nothing else, if there are two columns being retrieved then in the converter we need to swap them.
For now, its a manual job to switch them. You now know that rather then become bald, like me, check those LOV values and swap em if necessary ... now where is that bottle of Rogaine?