tag:blogger.com,1999:blog-25740336.post188563360811235187..comments2023-08-24T22:26:48.675+01:00Comments on The PeopleSoft DBA Blog: Global nVision performance optionsDavid Kurtzhttp://www.blogger.com/profile/00468908370233805717noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-25740336.post-12400186215058641422008-02-05T08:50:00.000+00:002008-02-05T08:50:00.000+00:00hi, when I tried to run your query in my DEMO, I f...hi, when I tried to run your query in my DEMO, I found that PSXLATITEM table is missing. How come we miss a PS table? Can you please throw some light on this?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-25740336.post-18278569114792231692007-10-18T08:41:00.000+01:002007-10-18T08:41:00.000+01:00Raphael - essentially yes. If the selector isn't ...Raphael - essentially yes. If the selector isn't on PSTREESELCTL, then I think you can (and probably should) get rid of it. This debris is left over from nVision reports that crash and do not clean up after themselves. If you are deleting a large proportion of the control table then you may want to consider rebuilding it in order to reset the high water mark of the table.David Kurtzhttps://www.blogger.com/profile/00924323960047469300noreply@blogger.comtag:blogger.com,1999:blog-25740336.post-27556875607006122302007-10-09T14:47:00.000+01:002007-10-09T14:47:00.000+01:00Hello David, very useful post. If I understood wel...Hello David, very useful post. If I understood well the use of the tree selector tables, does this mean all the following entries are the debris your mentioned?<BR/>"select * from PSTREESELECTnn<BR/>where SELECTOR_NUM not in (select SELECTOR_NUM from pstreeselctl"Raphaelhttps://www.blogger.com/profile/01611653257663126686noreply@blogger.comtag:blogger.com,1999:blog-25740336.post-85068323198618015382006-10-11T18:40:00.000+01:002006-10-11T18:40:00.000+01:00Hi David,
Although you would never catch me sayin...Hi David,<br /><br />Although you would never catch me saying this when I was at PeopleSoft, I like what you put together to update the tree performance options through SQL (we always discouraged people from updating Tools tables directly).<br /><br />If you wanted to do something similar for layouts with the performance options embedded in them, the information is stored in defined names in Excel.<br /><br />The name itself is NvsTree.{treename}. The contents of the name is a string of Y or N flags. (for example: ="YNNYN" ). The meaning of each position is as follows:<br /><br />Position 1 - Dynamic Selectors (<b>Y</b>es, <b>N</b>o)<br />Position 2 - Suppress Join (<b>Y</b>es, <b>N</b>o <b>S</b>ubselect Instead)<br />Position 3 - Range of values using >= and <= (<b>Y</b>es, <b>N</b>o... which means BETWEEN if not single values)<br />Position 4 - Single Values (<b>Y</b>es, <b>N</b>o)<br />Position 5 - Non-Specific Node Criteria (<b>Y</b>es, <b>N</b>o)<br /><br />I'd like to write up a similar post referencing this, and perhaps using the tree APIs instead of SQL for updating the tree tablesLarry Greyhttps://www.blogger.com/profile/02032092286499004382noreply@blogger.com