[14.2] Project Properties > Fields page does not load

[L.Elias]

We've upgraded our Test environment to 14.2 and are running in to an issue on the Project object. The Fields page for Project Properties View will not load, clicking the link leads to a blank page that just seems to reload an infinite amount of time without ever producing any output. We've already been working with support for the last week and have sent them a copy of our DB so they can take a better look, just wanted to see if anyone else has upgraded and seen anything similar.

 

Our initial upgrade went straight to 14.2patch3 and noticed this, so we rolled back to our backup taken just after 14.0 completed and we're having the same issue, so it doesn't seem related to the patch. We also tried installing patch 4 to see if that made any difference but it did not.

[navzjoshi00]

1. Is this for a few projects or all the projects in the system ?

2. Is this for one user of all the users ?

3. Have you tried to restart the apps ?

4. Have you checked the last_updated_by column and that it isn't -99 ?

 

NJ

[Andrew M]

is there anything in the logs?

[Suman Pramanik]

There are couple of tables that have been truncated from 12.1 to 13.0 and 13.1 for example ODF_Class, if you have created any lookup using that table and you are using that look up in any of your project attribute it will break. So the best to overcome this is to review all your custom lookups.

 

Next once you start upgrading from 12.1 to 14.2 and you face the problem look into the app ca log and probably a trace will give better understanding. In case you are facing any such issues please raise a case and we can work with you to resolve.

 

Regards

Suman Pramanik

[Deactivated User]

How many custom attributes do you have?

[L.Elias]

Many, I've tried deactivating all the ones that I could (the ones with checkboxes) but the page still doesn't load. And just to clarify for some of the above responses, I'm talking about the Fields page for Project Properties in the Views tab of the Project Object, NOT the actual view of a project, and anyone with admin access is having the same issue. The logs don't show anything relevant even with tracing on.

[Suman Pramanik]

Hi Elias,

 

Can you raise a case with support if not yet.

 

Regards

Suman Pramanik

[Deactivated User]

Deactivating is not enough. You have to delete them to make a difference.

How many is many? A couple of hundreds? More than five hundred?

Oracle or SQL?

[L.Elias]

About 50, maybe a little less, MSSQL. I tried deleting all the custom attributes and after quite some time, probably 2 hours, I finally got to the next screen and was unable to proceed because some of the attributes were used as the sort in some portlets or as virtual attributes, but it was all primarily one attribute

 

I went through and reset all the listed portlets to use a different default and published, but then when I went to remove the virtual attribute (The custom "OH Rank" attribute on the Project object was added as a virtual "Project Rank" attribute on the Team object), it is inactive and I cannot select it to delete it, there is no checkbox. Any ideas on how to force delete it?

 

Edit: I xogged out the Team object, and the Rank attribute does not appear in the output

[Deactivated User]

50 is well within the recommended limits and the page does display with hundreds of them. There must be something more to it.

Do as SumanPramanik suggests open a case with support if you have not yet done so and put enough effort into it to get to the bottom of it as there mights be something else in it which you do not yet experience.

[System]

Hi Lino - We're you able to get this issue resolved? If so please share the resolution here. Thanks! Chris

[L.Elias]

We just received some SQL scripts from CA late last week to run on our database. The underlying issue is that we apparently somehow ended up with a duplicate views on the project object. While its worked without issue on 13.0 (the DB shows the dupe view created a year ago I think they said), 14.2 just wouldn't play ball. Support provided scripts to remove the dupe and we've rolled back and run the scripts and upgrade again, so far so good.

[Nick Darlington]

Here was a validation query we came up with during the issue investigation that should help anyone else see if they are having something similar in their v13.x systems before they upgrade:

 

select code, view_type, principal_type, principal_id, view_subtype, object_code, partition_code, count(*)

from odf_views

group by code, view_type, principal_type, principal_id, view_subtype, object_code, partition_code

having count(*) > 1

 

The idea behind this query is that we would only expect a single view with a given name (code) and those other columns per partition code value (so if the object was partitioned, it wouldn't be abnormal to see more than one projectCreate_default view for example, but if it shows up in the query above where those other columns are also identical, then we almost certainly have a problem that support can inspect further and confirm or help remedy).

 

It was, in this case, also resulting in this error message in the logs (I've anonym-ized the content a little):

 

FATAL 2015-08-24 12:11:51,924 [http-bio-80-exec-28] web.VXSLServer (clarity:anonymous:XXXXXXX__XXXXXXX-XXXXXXXX-XXXXXXXXXX-XXXXX:odf.objectPropertiesFields) Transformation fatal error:Error in call to extension function {public static java.lang.String com.niku.union.xsl.NumberExt.formatPercent(java.lang.String,java.lang.String,int)}: Sequence contains more than one value; Java method expects only one; SystemID: file:/C:/ppm14204/META-INF/odf/vxsl/view/commonTemplates.xsl; Line#: 1048575; Column#: -1

; SystemID: file:/C:/ppm14204/META-INF/odf/vxsl/view/commonTemplates.xsl; Line#: 1048575; Column#: -1

net.sf.saxon.trans.DynamicError: Error in call to extension function {public static java.lang.String com.niku.union.xsl.NumberExt.formatPercent(java.lang.String,java.lang.String,int)}: Sequence contains more than one value; Java method expects only one

 

However, it can be possible that different views would produce different errors - it really just depended upon the attribute type it tripped over first, and it could easily vary in other systems/configurations.