We’ve all had or heard of the disappearing value button on lovs right? In the past my pat answer had been to check the ‘allow users to edit’ button. That, for some reason other than simply because it was a CHANGE, usually fixed the problem. I’m told, by another universe creator (I refuse to call us ‘developers’), that it isn’t consistently fixing the problem for him right now.
Robert and I were discussing it in the wrong place so this will serve to start up a conversation in the proper place.
Yep. Been there done that. This is actually on our web server. From what I understand the behaviour is consistently inconsistent. :? I’m told that in Webi, the button is gone. I’m told that in Zabo, it is there. All this is heresay. I like to observe things for myself.
I figured a thread on disappearing show values would be beneficial nevertheless![/quote]
This happened to me before, the only way we solved it was to have the WebI admin remove the universe and all the LOVs from the server and have the universe re-imported on next use.
It hasn’t happened since, but I sure would like to know of a better way to fix it.
On a more sensible note.
Have you tried re-exporting the universe with the LOVs?
Deleting the LOV on the webi server?
Checking the perms on the LOV (in case some overzealous process locked the LOV file or changed group/user perms
I haven’t use ZABO yet however doesent ZABO store the LOV’s as they are used on the local drive? Therefore they could still work/exist locally while the ones on the webi are locked/can’t use/corrupted etc
Willing to try it Its just a development server at the moment. People are that we’ll get to Prod and our buttons will disappear.
Been there.
Done that.
Will check.
Yes the Zabo lovs are local. The story I was getting was that the lovs exhibited different behavior in full client, zabo, and webi. I didn’t follow the workflow so I can neither confirm nor deny that.
Right now Hefeng is getting one fixed and one breaks. Trying the “slightly alter the wording of the prompt” method of showing the show button.
I seem to be having the same problem in WebI. I have a cascading prompt, and when the Show Values button is clicked, WebI thinks for awhile, then returns to the same screen but with no Show Values button.
This LOV has a prompt condition built into it, and has the options:
-Allow users to edit [unchecked]
-Automatic refresh before use [checked]
-Export with universe [checked]
Interestingly, it works for another object in the same universe, at a similar level of granularity, same class, etc…
I wonder if it matters at all that the parent object the user initially clicks Show Values for is defined used a substr(@SELECT()) pointing to another object. Shouldn’t affect it, but hey…
It does in testing, but it will not in the production system (over 1M unique values). I actually got this thing to work. The data source was down yesterday when I was testing, so perhaps the LOVs could not be pushed out. I wonder if this thing will continue to function when we remove the LOV off the driving prompt.
Indeed I have. The thing is, there’s nothing really to nest by. The hiearchy is very flat, and extremely wide. In this case, the way to go looks like this:
-The report needs to be filtered by the 1M unique values data: Value A
-Also needs filtering by prompt value: Value B (with LOV)
-Value B is determined based on Value A.
-Report contains a prompt for Value A, and Value B.
User inputs string for Value A
User click Show Values for Value B
Value B LOV pops up prompt for Value A
Same Value A is entered into prompt, and assoc’d Value B’s returned.
Select Value B, and go.
This will be viewed in WebI, so although displaying values in a hierarchy would look nice, it won’t work there.
I believe uniqueness at the granularity that the report writer is trying to achieve is determined by both Value A and Value B, so it looks as if there’s no easy way around the kludgy prompts.
With 1 million unique values – I wouldn’t build a LOV! I only supply List of Values for a reasonably small number of unique values, taken from a reference table, not the fact table.
Where we have huge possibilities, we supply no LOV – the user needs to specify a good value, not choose from a pick-list.
When I click on the “Show Values” button for an LOV, the resulting LOV list box comes back empty and the button turns to “Refresh List”. If I click on “Refresh List”, still no values. Any ideas?
Brian, you need to take a look at the LOV query on that object in Designer. Is it bringing back the correct table columns? Do you have select rights on the table? Also, is this happening to you in full-client, ZABO or WebI?
yes - the LOVs are set to be exported with the universe. Something I have found since my last note: this problem only exists in the WIJSP sample. When I run this through the WIS version, it seems to run fine??? Thoughts?
I’m not sure if my version of “the disappearing values button” is the same as the majority of this thread, but here is how I fixed it along with my theory as to how it MAY have happened.
The fix was totally in the report design (full client, if that matters). The document had multiple data providers (and multiple query tabs within each) that used the “offending” prompt. I removed the prompts completely from all data providers, and saved the file (also exited BusObj just to be safe). I then opened the document, added the prompt back to each data provider, and the values button re-appeared!
I know that the universe definition of the object using the prompt (but not the text of the prompt itself) changed during my report development. My theory is that it got confused by “which” object (and LOV?) to use, so it just grays out the button. By removing ALL references to the prompt, closing and reopening, and adding the prompt back, the single definition was restored. Note that I tried unsuccessfully to remove and re-add the prompt on a data provider by data provider basis. Again, until ALL references were gone, it doesn’t seem to “forget” about previous definitions.
Well, well … I found this in the 5.1.6 release readme as a known issue. “The “Values…” button is grayed if you create two queries, each containing a prompt and then change the prompt in the second query and run the first.”
I’ve just run into this issue myself. I have a predefined condition - no custom LOV - and the Values button is grayed out when you refresh the entire report.
The report contains 3 DP’s, each with unique conditions - there’s no duplication of conditions between the reports. Curiously, if you refresh just the data provider containing that prompt, BO will allow you to show the LOV.
I’ve tried pretty much everything I’ve seen suggested in this forum to get around the issue without any luck. I’ve deleted all the conditions in the report, saved it, quit BO, came back in, and replaced them. Doesn’t work. I’ve tried building my own condition on that object within the report, instead of using the predefined condition - no dice, I still don’t get a LOV when refreshing the whole report. I tried purging all the local LOV’s, refreshing them on the Universe side, changing all the options on the Universe side (allow users to edit, etc.), even turning the LOV option off and back on again at the Universe level. Nothing worked.
Curiously, if I copy the object in the Universe and build an In List condition in the query panel for that copy of the object, then the Values button is available. So it looks like somehow the LOV for the original object is corrupted, but that whatever it is I’m doing isn’t clearing that corruption.
Any ideas? Should I just go ahead, delete the original object, and replace it with the new one? What would the consequences be?
(BOB member since 2002-06-11)
(BOB member since 2002-08-20)
Its just a development server at the moment. People are 
that we’ll get to Prod and our buttons will disappear.
(BOB member since 2002-08-28)