I’m trying to compensate for bad data by generating very specific LOVs for some objects in UDT. I know that if the business sees certain values, they will get confused - these values have no data recorded against them and are part of a wider systems merge, so I just want to hide them completely.
The only way I can restrict my LOV is by using a not-like pattern match on the notes column. I know it’s not ideal, but it is only an LOV. I have no issues with the time taken - the query runs quickly.
What I can’t do is a pattern match on a long string - anything more than 20 characters and Designer simply tells me there are no rows returned. The same code runs fine in a query tool with the correct LOV values returned.
Anyone else come across this? I’m having to split my pattern matching into small chunks and then deal with nulls separately. It’s doable, but much harder to maintain down the line…
So I got a change made a database level to enable me to identify historical records more easily - which is great, but leads me on to another question…
Is there any easy magic way to generate a full refresh of every LOV in a universe? Anybody have anything written? I’m losing the will to live regenerating each one manually!
I’ve never seen a way of doing this. There are some clever people out there though! Why are you regenerating them yourself…can’t your users just refresh them as required? Or are you worried about them seeing old confusing results without you forcing the refresh?
Go to Tools > Lists of Values > Edit a List of Values. The window that comes up has 4 options, one of which is Refresh. You can highlight one or more classes to refresh the LOV’s in those classes only.
I build all my LOV’s in a hidden class named LOV Refresh. If I want to refresh them I just unhide the class, go to the Lists of Values window, highlight the LOV Refresh class and select Refresh. Then hide the class again, save and export the universe.
@Norm - Thanks. I know how to do it, but I just have issues with Bobj correctly processing oracle code.
@Nick - Both! But mainly because our CVs are stored in a strange way in one huge file, which requires me passing a unique value for each CV - so I have to add this in manually. And some take an age to refresh, but the data doesn’t change often, so it’s easier to do it once rather than the user do it every report. And now we have a load of new “historical” values which I want to hide completely from the users.
(BOB member since 2005-03-01)
(BOB member since 2002-07-10)