I am customizing some LOV’s in my universe to take advantage of the Hierarchical View capabilities in BO. I would like to have these LOV’s stored in the repository, so that all users of my universe will be able to take advantage of this design approach. Currently my implementation of BO is in the design phase, so I am running the client tools and testing everything from one workstation. The BO repository is on another machine. If I customize an LOV, check “Export w/Universe” and “Automatic Refresh before use” from the Object Properties/Properties tab, and then export the universe the LOV will be downloaded to my workstation every time I import the universe in Designer (whether or not the file has been deleted). This is the behavior I am wanting. If, however, I delete the LOV, and then load up Reporter, Reporter will generate a new default LOV that does not reflect what is being stored in the repository. I am running version 4.1.2 of Business Objects.
Hi Will,
The list of values issue is not a new one, as a matter of fact there is a patch
out that is suppose to fix the problem.
let me share our problem, and partial resolution to date with this:
6 to 8 months ago we brought the List of Values issues up with BO. The issues were many, but the only one that was preventing production functionality was the following:
When a Designer exported a universe with a set of custom built List of Values (LOV) the Document Domain would loose its mind. It would only allow 99 LOVs at that time as well. In the past few months BO has worked on a service pack to resolve these issues. Customer Service Pack #21 resolves many of the LOVs issues.
We tested the CSP#21 when it became available. The results of the test were poor at best. The LOVs that should get stored in the document domain were not storing consistently. We isolated the entire environment and ran clean exports on it. By doing this we were able to pinpoint a problem with BO that really has nothing to do with the CSP#21, but rather with the export function in the designer tool. When the document domain gets created BO builds the individual objects in the Oracle scheme with the default storage parameters. We isolated the Oracle table BO uses to maintain the LOVs and watched the impact following an export of a universe with custom LOVs. It was then that we discovered that the document domain object housing the LOV details was running out of extents. The designer export function returns a successful export message when in fact the table used to store the LOVs has walked over itself. This causes very unexplained and confusing data movement in the domain.
WHERE WE AT NOW?
After locating this problem we opened up the extents on the doc domain object and have not seen any abnormalities yet. Success!!! The CSP#21 must be used for DESIGNERS (and only designers) in order to resolve the custom LOV issue. If the CSP#21 is not used the risk is that only 99 LOV can be stored and many other problems as well (see readme file with CSP#21 for more details).
I hope that this is helpful. I know that there have been many postings on this issue, and if this information that I am sharing helps anyone out there, then YAHOO!!! laurenf@bellatlantic.net
“Buittitta, Will” wrote:
I am customizing some LOV’s in my universe to take advantage of the Hierarchical View capabilities in BO. I would like to have these LOV’s stored in the repository, so that all users of my universe will be able to take advantage of this design approach. Currently my implementation of BO is in the design phase, so I am running the client tools and testing everything from one workstation. The BO repository is on another machine. If I customize an LOV, check “Export w/Universe” and “Automatic Refresh before use” from the Object Properties/Properties tab, and then export the universe the LOV will be downloaded to my workstation every time I import the universe in Designer (whether or not the file has been deleted). This is the behavior I am wanting. If, however, I delete the LOV, and then load up Reporter, Reporter will generate a new default LOV that does not reflect what is being stored in the repository. I am running version 4.1.2 of Business Objects.