Data in inv_hierarchies table

[Anon Anon]

I'm getting some unexpected results from the inv_hierarchies table. I'm hoping someone here can shed some light on it for me. I was assuming that in this table every investment would at a minimum have a record where the parent-id is null and the child_id is itself. This would represent the top of the heirarchy or a standalone investment. [color=#ff0101] Is this a true statement ? Can anyone confirm this for me ? [color]

We have found some child_ids where there is no such record (parent is null and child is self) exists and it is causing a portlet to error out. It has happened to both Project and Program records. [color=#ff0101] I want to determin if we have bad data in the table or.... if the data is good, can somone explain the scenario where not having the record in the table is valid....[color] I would then need to fix my portlet.

Thanks,
Ben

[Anon Anon]

I have plenty of records where a INV_INVESTMENT.ID does not exist as a child_id with a null parent_id in INV_HIERARCHIES

Not sure if that helps you any though :wacko: .... there was a "TIP" about these tables a while back ; CA Clarity Tuesday Tip: Inv_Flat_Hierarchies

[Deactivated User]

I don't think there should a record for every investment. Only if there is a parent-child relation plus the orphans and errors. If I recall correctly there were some bugs as well.
There are previous threads about those if you search the forums.


Martti K.

[Anon Anon]

Thought I would share a little discovery we made.... It appears that the system records info to this table differently depending on how you add investments to the heirarchy. If you use the Heirarchy tabs with the investment it appears to update the existing record by changing the null parent_id to having an ID.... leving just the one record in the table. If you add investments using the subprojects of a program this creates a second record... so you have 2 records.. one with a null parent and one with the parent ID. I think the later should be the correct way to populate the table so that you can pick an investment in the middle of a hierarchy and look at it as if it were the top by selecting the row with the null parent.

Either way.... I think this is an issue that I will bring to CA... it should not populate the table 2 different ways depending on how you build your heirarchy on the front end.

I'll let you know what CA has to say about it !!!

[Anon Anon]

Does anyone else find this response from CA as disturbing ? What am I missing ? How can they say that it makes sense to record the data to the DB table 2 different ways when adding a child to a parent ?


Hi Ben.
I did not call you based on the relative time.

Clarity is working as designed.

1. When a child is added to a parent via the SUBPROJECTS tab, the record in INV_HIERARCHIES with parent_id == NULL does not get updated.
Instead, a new record with a valid parent_id gets inserted into the INV_HIERARCHIES.

2. When a child is added to a parent via the HIERARCHIES tab, the record in INV_HIERARCHIES with parent_id == NULL gets updated with the valid parent_id.

These two actions have separate outcomes in order for the hierarchy to be represented in table form.
There are not any orphans in the system.


Thank you,
CA Support

[Deactivated User]

I find it disturbing.

Clarity is working as designed.

simply does not mean that it is properly designed and the design requirement is acceptable to users. It is just a a way for support to get the case closed unresolved.


I don't by the statement about orphans either. See
8776681

Where Michiel Meijler writes
We have experienced that there is different behavior of the system between the sub-project functionality and the Add Child button in the Hierarchy functionality.

Maybe this will help in yout further investigations.
in 15/10/10


Martti K.

[Edmund_Jones]

Hi Martti,

Thanks for your input.

You’re right that design issues don’t follow the "normal" path but all of us here at CA do want to hear about them. They will be deemed changes (not enhancements!) and thus we would very much appreciate it if as and when they are encountered people place them onto the ideation page for a more direct conversation with Product Management team. It’s true this will normally close the support ticket but the idea behind the process is that the issue will then be transferred to the ideation page, which is a great way for these suggestions to be publicly shared whilst simultaneously giving them very good visibility within CA.

Any concerns then do please contact me on [e-mail] or I can call you. I would welcome the chance to hear your feedback on our processes.
Many thanks
Ed

CA Support

[Deactivated User]

Hello Edmund,

My latest impasse was with
Location Browse lookup in r8.1 to v12.1 upgrade
99241051
since that did not fly i started a new thread for what I thought would be a work around
How to display PAC_MNT_PROJECTS.DEPARTCODE and PAC_MNT_PROJECTS.LOCATIONID
Search?


To me it sees that the attribute definition is not correct in the Studio and there is no simple way to display what is defined and what is a standard field in ODF_CA_PROJECTS.
Which translates that the product may work as designed, but not as decribed. (to say nothing about desired)

The closure to 21141670 01 - LOCATION BROWSE LOOKUP_PARAM_L was that if I want that I should have services involved.

This would not fly as an idea either judging on the number of comments of those threads.

Martti K.

[Edmund_Jones]

Good morning Martti

We will consider everything that gets put onto the ideation page as a concern around design or otherwise, and it's not just about which one gets the most votes so I would still encourage you to try this route. You will at least get an answer!

As said before drop me a line at [e-mail] if you would like to discuss anything.

Many thanks
Ed

CA Support

[Deactivated User]

Hello again,

Thank you for your response.
Though Nick has been very active, started a new behaviour and provided help in areas which normally would go to support and services or out right to consultancy you post is first of a kind:
It goes to the area as designed not necessarily as desired and consequently what is the real customer need.
That sounds like orientation more towards the customer.

I do think that one role of support is to tell the customer if he or she has encountered a bug or if the product is used and functions as designed or not. Items that do not fall into those areas can be handled differently.

I must clarify my thinking a little before I put anything on the ideation page as there are several aspects in the example like the design, the description, the documentation of the product, display of standard object fields and question of whether my need is standard or not.

To modify your post a little I wish everything that gets put onto the Technical Docs message board as a concern around documentation were also a concern.

With regards

Martti K.