Re: Should short name always be equal to long name for object_statistics?

On 24-Feb-2015 10:44 -0600, rob@xxxxxxxxx wrote:

I opened a ticket with this. <ed: ObjLongName IncorrOut>
I'm getting the impression that someone totally misread the Retrieve
Short Name (QDBRTVSN) API and thought they could use that to
'retrieve' the long name. (This API was mentioned in the ticket.)

Use of anything [e.g. an API] to get the long name of each object, if obtained separately from the listing feature that would have locked the _object_ to obtain the other information about each object in just one-pass, would be an inherent flaw in the design of the Object_Statistics UDTF; something I had alluded in a prior reply, likely would be[come] an issue. The UDTF could lock every object [of a type that might have a long name and] that would be listed, thus omit any since-deleted, but that surely would not be the most desirable.

I think they now realize their mistake. I think they're going to
take baby steps to fix this. First step will be to get this to work
for 'Table' objects. They will query against SYSTABLES to get the
long table name. (again, mentioned in the ticket).

More appropriate would be to get the long name directly from the QADBXREF file for any *FILE with an attribute [DBF or DDMF] for which an SQL Long Name is supported; thus all of VIEW, INDEX, ALIAS, and TABLE could have that [possibly residual] attribute. Yet that is still flawed, if performed outside the one-pass retrieval of object info that holds the lock across all of the _retrieve_ work; i.e. the retrieval of all object information really needs to be performed as an atomic operation.

I'd like to think
about this before this really starts to get to be one huge CASE
statement, or worse, becomes a permanent restriction.
<<SNIP>>

Perhaps they should be enhancing the underlying implementation of the "List Object" feature that is being invoked by the UDTF, so as to [enable that feature to the capability to ask for and to] return the SQL long-name from any object types that support one. The dependence on a two-pass retrieval of information about the objects will assuredly effect occasional incorrect output due to effective concurrency :-(