Ok, here is the setup and an obscure question… I am having issues with exports, lov’s are not working correctly (but only on the designer’s box)… I sent a trace to BO, but while I wait, I went thru the repository…
My question, in two parts is this: does anyone know what table the m_uni_n_lov ID in the obj_m_universes table ties to, and if so, should this id be UNIQUE in the obj_m_universes table?
Any insights on this would be very helpful.
Brent
Listserv Archives (BOB member since 2002-06-25)
In a message dated 00-03-14 08:29:42 EST, you write:
Ok, here is the setup and an obscure question… I am having issues with
exports, lov’s are not working correctly (but only on the designer’s box)… I sent a trace to BO, but while I wait, I went thru the repository…
My question, in two parts is this: does anyone know what table the m_uni_n_lov ID in the obj_m_universes table ties to, and if so, should
this
id be UNIQUE in the obj_m_universes table?
I don’t know what that column references. I do know that it probably has nothing to do with object list of values. Here’s my guess…
In my test repository, I have 8 universes listed in my obj_m_universes table. Three of them have a value of 1 for this field, the rest of them have 0 (zero). Only the three that have a 1 actually show up on my import list, or in supervisor. I am guessing that the others are hidden because they have been deleted from the repository. Testing this, I did a Scan / Repair / Compact on my repository. After doing that, the universes that have a value of 0 in that field were gone. I suspect that was a “marker” for deleted (but not purged) files.
In other words, when building a list of universes, BusObj SQL would be something like:
select universe_name
from obj_m_universes
where m_uni_n_lov = 1
You could also read this as “where lov is true (yes)”. Again, it’s a guess, but one that I feel pretty good about. And that’s my “final answer”. 
To look for LOV information, the “real stuff”…
Look in the UNV_OBJCONTENT table. That’s in the universe domain, not in the security domain. The OBJ_LOVID corresponds to the X_DOC_N_ID in the OBJ_X_DOCUMENTS table. The LOV is stored as a document.
That’s why if you don’t have a document domain with the same connection information as your universe domain you can’t export list of values with the universe. Designer must find all the tables (universe and document) using the same connection info.
Regards,
Dave Rathbun
Integra Solutions
www.islink.com
Listserv Archives (BOB member since 2002-06-25)
Wow, that is the most clear response to this yet… Thanks, Dave (Dr.Rathburn, as you are known here)… I was concerned that the numbers got repeated, once in a while, in that lov field, and that this was causing a problem… just reaching. But, in my repository I would have to change this:
select universe_name
from obj_m_universes
where m_uni_n_lov = 1
would become
select universe_name
from obj_m_universes
where m_uni_n_lov <> 0
( my numbers range from 0 to 200s…)
I went back and checked my doc domain / univ domain connections, and they all seem to match (exactly, I have heard spacing and capitalization matter) - nothing…
If anyone has seen this issue of lov folders ‘stacking up’, I am wide open for suggestions
Brent
<<
I don’t know what that column references. I do know that it probably has
nothing to do with object list of values. Here’s my guess…
In my test repository, I have 8 universes listed in my obj_m_universes table.
Three of them have a value of 1 for this field, the rest of them have 0
(zero). Only the three that have a 1 actually show up on my import list, or
in supervisor. I am guessing that the others are hidden because they have
been deleted from the repository. Testing this, I did a Scan / Repair /
Compact on my repository. After doing that, the universes that have a value
of 0 in that field were gone. I suspect that was a “marker” for deleted (but
not purged) files.
In other words, when building a list of universes, BusObj SQL would be
something like:
select universe_name
from obj_m_universes
where m_uni_n_lov = 1
You could also read this as “where lov is true (yes)”. Again, it’s a guess,
but one that I feel pretty good about. And that’s my “final answer”. 
To look for LOV information, the “real stuff”…
Look in the UNV_OBJCONTENT table. That’s in the universe domain, not in the
security domain. The OBJ_LOVID corresponds to the X_DOC_N_ID in the OBJ_X_DOCUMENTS table. The LOV is stored as a document.
That’s why if you don’t have a document domain with the same connection
information as your universe domain you can’t export list of values with the
universe. Designer must find all the tables (universe and document) using the
same connection info.
Regards,
Dave Rathbun
Integra Solutions
www.islink.com
Listserv Archives (BOB member since 2002-06-25)