NV: “[TREENAME] is undefined, inactive, or invalid. (28,21)” (Master Resolution
This resolution contains several information regarding error message: “[TREENAME] is undefined, inactive, or invalid. (28,21)” in nVision.
=======================================================
”[TREENAME] is undefined, inactive, or invalid. (28,21)”
IMPORTANT: Do not confuse the above error with “Treename is not found or is marked as invalid. (28,106)”.
The error “[TREENAME] is undefined, inactive, or invalid. (28,21)” occurred after a user changed the DEFAULT SETID for a business unit in UTILITIES, USE, TABLESET CONTROL, TABLESET RECORD GROUP CONTROLS.
The following information helps to explain how nVision determines what setid to use in selecting a tree. It also explains the relation to TABLESET CONTROLS and record group FS_21.
There are two key points that you should keep in mind:
1. When the user is creating or revising a layout, we presume that the layout can be used by a number of different business units, all of which have enough in common that they can use the same report. Because we want the layout to have maximum flexibility (Can be used by business units for which the same tree references mean different things), we use a layout SETID as an indirect pointer to the trees that the prospective using business units have in common. This SETID in turn points to trees that are similar to those used by the various business units. The design-time SETID is entered on the Prompt dialog box, which is available at any time using the PROMPT button in the Layout Definition.
The layout SETID supports prompting and validation when creating or modifying the layout, and is ignored at run time.
2. The REQUESTING BUSINESS UNIT field in Report Request is the starting point in determining what SETID will be used. The system then looks at TABLESET TREE CONTROLS in UTILITIES / TABLESET CONTROL for the requesting BU. Under TABLESET TREE CONTROL, nVision looks at two pieces of information; The DEFAULT SETID (The same one seen on the panel TABLESET RECORD GROUP CONTROLS.) and the TREE CONTROLS. Under TREE CONTROLS, you can specify the actual name of a tree and the corresponding SETID that nVision is to use for that tree and BU. If there is an entry for the given tree under TREE CONTROLS, that takes precedence. If there is not an entry under TREE CONTROLS, then the DEFAULT SETID will be used in determining what tree to use.
For nVision reporting, the RECORD GROUP of FS_21 under TABLESET RECORD GROUP CONTROLS is not used.
(Therefore, the check-box FORCE USE OF DEFAULT SETID is not looked at for nVsion reporting.)
Additional Notes from Development: “I don’t know why the FS_21 group exists, except that all customer-defined records need to belong somewhere. In fact, much of our software, especially views we deliver, assume that the SETID for a given tree’s nodes (or levels) is the same on both the “system” table (PSTREENODE, PSTREELEVEL) and the “user” or “customizable” table (PS_TREE_NODE_TBL, PS_TREE_LEVEL_TBL, or other tables specified in the tree structure. As a result, I don’t expect our reporting tools to access the tree records through the FS_21 group much. However, they might be important to the panel processor and/or application logic.”
Error on renaming the Tree, Invalid, Undefined or Inactive Tree
It is a known problem and there is a document in the T/T which lists the various resolutions. NV: Tree undefined or invalid. This is a very common error message in nVision when you’ve modified a tree and are trying to run a layout that previously ran just fine. This also occurs if you make the changes to the report manually using tree nodes/criteria from a newly created tree. Another symptom is that when you are trying to add criteria using nVision/Layout Definition from a new tree you’ve created, the tree doesn’t show up in the list box. Here are some possible causes and solutions.
1) TableSet problems.
A) nVision doesn’t recognize the trees for the particular setid. Go to the Utilities window and select TableSets /TableSet Controls/TableSet Tree Controls. Add the Tree Names that you want to report on to this panel. If more than one tree is necessary, use add function (F7) to add more Tree Names to the panel.
B) Be sure you have implemented the fix R-CJC-51 which relates to FS_21 on the Utilities menu.
The cause of this problem was that the PS_TREE_NODE_TBL and PS_TREE_LEVEL_TBL records were put into record group FS_04 which is also the tableset record group for detail & summary ledgers.
The problem occurs when a tree is created under a setid (eg WORLD) and the tablsetid indirection for record group FS_04 is different than the tree setid (eg NEWGN). When you’re adding nodes and levels to this tree the tree editor is doing setid indirection by looking at record group FS_04.
2) Effective dating problems. Clone the tree (File, Save As) and use the effective date of 01/01/1900. This will rule out any effective dating problem. Also be sure that all the nodes on the tree have that same date.
An example of how to set up dates:
The accounts (nodes on tree) effective dated 08/01/95
The tree effective dated 08/01/95
The nVision layout effective dated 08/15/95
The nVision report request effective dated 08/24/95
Don’t forget that the effective date of the tree to be used in the report is specified on the report request. If you use the ledger’s Main As Of Date, this is the date that is defined to be the as of date on the Ledger Definition panel.
This date can be over-ridden by the specifying a date for the tree in the Report Request, if you are getting the error msg when you run the report. The date used by nVision for accessing trees when building the report is different from the one used when the report is run.
3) Problems with tree selector numbers or version numbers. Try doing the following:
a) Delete the Swap files.
b) Rename a node from the tree, and save it. This will ensure that the tree selector table is in sync. Delete a detail value from the tree, re-add it and save the tree again. (This should update the version number in the PSLOCK table. VersionTDM & VersionTAM.) A Save As will also accomplish the same thing.
If you still can’t see the tree after doing steps a) and b):
c) Build a brand new report layout to run against the tree.
d) Save the tree with a new name. Re-save it with the old name. Delete the swap files. Try running the report. If problem persists, re-create the report. If problem persists, re-create the tree, then re-create the report.
4) After an upgrade the nVision reports are not recognizing the trees. It is not pulling in the tree information. Apparently the following DLLs were causing the problem (PSNAM.DLL, PSNLT.DLL, PSNXL.DLL and PDSPS.DLL ).
5) Under very odd circumstances, nVision brings in the wrong setid for the report, and hence the wrong trees as well. Resolution: go into the panel PEOPLETOOLS > UTIILITIES > USE > RECORD GROUP > U/D select FS_21 TREE NODE AND LEVEL and in upper right click the check box, FORCE USE OF DEFAULT SETID. You will be able to see whether the report is bringing the right Tree in the first place by looking at the trace.
6) A SYSAUDIT AND A DDDAUDIT will show the integrity of the tables and views. If still running into problems, run these two reports, (should take less than a 1/2 hour each), and make sure the output is “no rows found”. If there is output with rows found, those problems have to be taken care of before you can proceed.
Node (XXXX) is undefined, inactive, or invalid (28,20)
While attempting to run a nVision report receive an error: Node (XXXX) is undefined, inactive, or invalid (28,20).
Check for duplicate trees with different effective dated rows.
TREENAME is undefined, inactive, or invalid. Resolve this issue by resaving the tree.
“Node (XXXX) is undefined, inactive, or invalid (28,20)”
If a node name has been selected within the criteria of the layout that does not exist within the tree pointed to, then the above error will occur. Frequently, customers will rename trees and not rename the node criteria within the layout (ie. Node in tree is named “Revenue” and criteria in layout is “Revenues”).
To correct this, edit the criteria in the nVision layout either via nVision Layout Definition, or directly in the criteria in Column A or Row 1. To see Col A, Row 1: nVision, Options, and check the “Show Column and Row Criteria” checkbox.
Error when running an nVision report for a particular BU. Run the same report for a scope that includes this same BU and several others, the report runs, but not all of the data is retrieved according to the report layout. Receive the following error message: “Tree ACCT_TREE undefined, inactive, or invalid. (28,21).” Detail explanation: “nVision could not access the specified tree, because the name is incorrect or the tree has been saved in an invalid state.”
Check the SETID of the tree to the default setid of the requesting business unit. nVision uses the “Default Setid” as the setid for all of the trees in the report (unless specific trees are set up in TableSet Tree Controls).
Another reason you can get this error: The Main As Of Date on the Report Request is less than the effective date of the tree. nVision will not recognize trees with an effective date in the future. For example, if the Main As Of Date on the Report Request is 1/1/1995 and the tree’s effective date is 1/1/97, this tree cannot be accessed in nVision. The effective date problem can also occur if the Report Request uses the date from the “Business Unit Table” and this table isn’t populated with an As Of Date. Check this by going into Establish Business Units and looking at the As Of Date. If this is blank the reports won’t work if you tell them to use the date from the business unit table.
Tree INCOME_WMLOP undefined, inactive, or invalid. (28,21)
Looks like a user changed the default setid for one of the business units. What is disturbing is that one of the machines was still able to process reports until the cache was purged.
Problem was with SetID GO->PeopleTools->Utilities->Use->Table Set Controls->Table Set Group Controls. The value Default SetID was set to WMLOP and should have been set to TRUCK which is the shared accounts SETID/Business Unit. Problem was identified by comparing FPRD to FCPY (which was an image of FPRD as of 09/28/00) and the table PS_SET_CNTRL_TBL.
In versions 7.0x and 7.5x these tables for GL business units effected are:
PS_BUS_UNIT_TBL_GL
PS_BUS_UNIT_TBL_FS
PS_SETID_TBL
PS_SET_CNTRL_TBL
PS_SET_CNTRL_GROUP
PS_SET_CNTRL_REC
PS_BU_JE_ID_CFS
PS_BU_JE_IC_CFS
PS_CONS_BU_LED_TBL
PS_BU_JE_BS_CFS
XXX tree Undefined, Inactive, or Invalid. (28,21) OR sometimes (28,20)
Created a layout that goes against his summary tree called F_SUM_PROJ_ESD. The layout itself runs fine and creates a valid instance. (Using a requesting BU of ESD and is checking Data From Requesting BU only.) While in the instance, perform a drilldown on the total line of his imploded values and the drilldown runs successfully. However, if you drill down on any of the detail lines within the inploded total, immediately get the error “F_PROJ_D_ABM_TUS Undefined, Inactive, or Invalid. (28,21)”. The drilldown is a custom drilldown. Detail tree is F_PROJ_D_ABM_ESD (setid of ESD) and his summary tree is F_SUM_PROJ_ESD (setid of ESD). The structure used on the summary tree (custom structure) points to the detail tree F_PROJ_D_ABM_ESD. (ESD and TUS are two of the 6 business units.). Tableset Tree Controls have been reviewed and are accurate with a default setid of ESD and none of the project trees listed. When he enters the Summary Ledger definition under setid of SHARE (no entry of ESD) the tree specified is F_PROJ_D_ABM_ESD. The ledger in the layout and ledger definition is MR_AESD.
To fix this renamed all his summary chartfields with different names and create 6 new tables. This has fixed the problem.
Another similar problems with summary ledger drilldown getting the following error message: “Node XXX undefined or invalid in tree YYY. (28,20) ” The same solution fixed this error as well.
“TREENAME is undefined, inactive, or invalid. (28,21)”
PROBLEM: The above error occurred after a user changed the DEFAULT SETID for a business unit in UTILITIES, USE, TABLESET CONTROL, TABLESET RECORD GROUP CONTROLS.
The following information helps to explain how nVision determines what setid to use in selecting a tree. It also explains the relation to TABLESET CONTROLS and record group FS_21. Some of the information is taken directly from an email from development.
There are two key points that you should keep in mind:
1. When the user is creating or revising a layout, we presume that the layout can be used by a number of different business units, all of which have enough in common that they can use the same report. Because we want the layout to have maximum flexibility (Can be used by business units for which the same tree references mean different things), we use a layout SETID as an indirect pointer to the trees that the prospective using business units have in common. This SETID in turn points to trees that are similar to those used by the various business units. The design-time SETID is entered on the Prompt dialog box, which is available at any time using the PROMPT button in the Layout Definition.
The layout SETID supports prompting and validation when creating or modifying the layout, and is ignored at run time.
2. The REQUESTING BUSINESS UNIT field in Report Request is the starting point in determining what SETID will be used. The system then looks at TABLESET TREE CONTROLS in UTILITIES / TABLESET CONTROL for the requesting BU. Under TABLESET TREE CONTROL, nVision looks at two pieces of information; The DEFAULT SETID (The same one seen on the panel TABLESET RECORD GROUP CONTROLS.) and the TREE CONTROLS. Under TREE CONTROLS, you can specify the actual name of a tree and the corresponding SETID that nVision is to use for that tree and BU. If there is an entry for the given tree under TREE CONTROLS, that takes precedence. If there is not an entry under TREE CONTROLS, then the DEFAULT SETID will be used in determining what tree to use.
For nVision reporting, the RECORD GROUP of FS_21 under TABLESET RECORD GROUP CONTROLS is not used. (Therefore, the check-box FORCE USE OF DEFAULT SETID is not looked at for nVsion reporting.)
Tree Invalid or Undefined
This is a very common error message in nVision when you’ve modified a tree and are trying to run a layout that previously ran just fine. This also occurs if you make the changes to the report manually using tree nodes/criteria from a newly created tree. Another symptom is that when you are trying to add criteria using nVision/Layout Definition from a new tree you’ve created, the tree doesn’t show up in the list box. Here are some possible causes and solutions.
1) TableSet problems.
A) nVision doesn’t recognize the trees for the particular setid. Go to the Utilities window and select TableSets /TableSet Controls/TableSet Tree Controls. Add the Tree Names that you want to report on to this panel. If more than one tree is necessary, use add function (F7) to add more Tree Names to the panel.
B) The cause of this problem was that the PS_TREE_NODE_TBL and PS_TREE_LEVEL_TBL records were put into record group FS_04 which is also the tableset record group for detail & summary ledgers. This is incorrect.
The problem occurs when a tree is created under a setid (eg WORLD) and the tablsetid indirection for record group FS_04 is different than the tree setid (eg NEWGN). When you’re adding nodes and levels to this tree the tree editor is doing setid indirection by looking at record group FS_04.
Our resolution was to add a new record group FS_21. The PS_TREE_NODE_TBL and PS_TREE_LEVEL_TBL were moved from FS_04 to FS_21. The peoplecode for populating the initial tableset sharing values was modified to hardcode the SETID value for rec group FS_21 to the SETCNTLVALUE for the tableset group. This field is also grayed on rowinit when entering the tableset group control panel to prevent a user from changing it to anything else.
2) Effective dating problems. Clone the tree (File, Save As) and use the effective date of 01/01/1900. This will rule out any effective dating problem. Also be sure that all the nodes on the tree have that same date.
An example of how to set up dates:
The accounts (nodes on tree) effective dated 08/01/95
The tree effective dated 08/01/95
The nVision layout effective dated 08/15/95
The nVision report request effective dated 08/24/95
Don’t forget that the effective date of the tree to be used in the report is specified on the report request. If you use the ledger’s Main As Of Date, this is the date that is defined to be the as of date on the Ledger Definition panel.
This date can be over-ridden by the specifying a date for the tree in the Report Request, if you are getting the error msg when you run the report. The date used by nVision for accessing trees when building the report is different from the one used when the report is run.
3) Problems with tree selector numbers or version numbers. Try doing the following:
a) Delete the Swap files.
b) Rename a node from the tree, and save it. This will ensure that the tree selector table is in sync.
OR Delete a detail value from the tree, re-add it and save the tree again. (This should update the version
number in the PSLOCK table. VersionTDM & VersionTAM.) A Save As will also accomplish the same thing.
If you still can’t see the tree after doing steps a) and b):
c) Build a brand new report layout to run against the tree.
d) Save the tree with a new name. Re-save it with the old name. Delete the swap files. Try running the report. If problem persists, re-create the report. If problem persists, re-create the tree, then re-create the report.
4) After an upgrade the nVision reports are not recognizing the trees. It is not pulling in the tree information. Apparently the following DLLs were causing the problem (PSNAM.DLL, PSNLT.DLL, PSNXL.DLL and PDSPS.DLL ).
After sending the customer the correct DLLs for his PS Tools version it corrected the problem.
5) One last thing, under very odd circumstances, nVision brings in the wrong setid for the report, and hence the wrong trees as well. Resolution: go into the panel PEOPLETOOLS > UTIILITIES > USE > RECORD GROUP > U/D select FS_21 TREE NODE AND LEVEL and in upper right click the check box, FORCE USE OF DEFAULT SETID. You will be able to see whether the report is bringing the right Tree in the first place by looking at the trace.
6) A SYSAUDIT AND A DDDAUDIT will show the integrity of the tables and views. If still running into problems, run these two reports, (should take less than a 1/2 hour each), and make sure the output is “no rows found”. If there is output with rows found, those problems have to be taken care of before you can proceed.
7) tree needs to be specified PS_LED_FLD_TBL .
