PeopleSoft

Entries from March 2008

Installing MySQL on OS X 10.5

March 23, 2008 · Leave a Comment

Installing MySQL on Mac OS X 10.5+

This is a very brief description on how to download the source tarball for MySQL, compile and install MySQL on OS X.

I’m currently using a Mac Book Pro 15″ with the maximum amount of memory 3 GB, 2.33 GHz, Intel Core 2 Duo, 667 MHz Bus and a 120 GB internal disk. I have several external drives including a LaCie 250 GB 800 Firewall drive and a USB Seagate FreeAgent 120 GB drive.

Why You Would Build Instead of Use a Package to Install MySQL

When new Operating Systems are released sometimes there aren’t installers available for the new release or the installer may break when a minor release update package is installed. Compiling source files along with choosing the appropriate configuration options can produce optimized, machine-specific binaries, etc.

Step One is to determine what the latest version of MySQL is. There is now a packaged installer for Leopard, that was not the case at the end of last year when Leopard shipped in the late fall.

The following link points to a page on Sun Microsystem’s web site:

The heading for this page is 2.4.10 Installing MySQL on Mac OS X

There are installation links for the various operating system that MySQL runs on listed in the right side bar. There are several other links on this page that point to various locations within Sun Microsystem’s web site that covered the various tasks, features, etc. One of the links points to the location where you can obtain MySQL. That link is:

Following the above link will take you to the MySQL Downloads Page which contains the latest version information as well as the various MySQL Products offered by Sun Microsystems (Sun purchased MySQL last year). There are Quick Jump links to various community sites. Sun offers the MySQL Community Server as well as an Enterprise edition.

Towards the bottom of this page you’ll see a section with the title MySQL Community Server. It is here where the information for the Current Release, Upcoming Releases and Older Releases is displayed. Typically all vendors suggest using the Current (Stable) Release and if you are looking for a binary package this is your best shot at locating a pre-built packaged installer.

This link: will lead you to the Mac OS X (package format) downloads and the Tar Packages downloads are listed right below. There are hot links to pull up the platform notes for each section and you can browse down the page until you find your OS X version. There is a packaged formatted installer for Leopard now (OS X 10.5). I’ve tested the package and I was able to easily install MySQL and immediately start using it without even rebooting.

After testing the package install I moved on to downloading the appropriate Tar Package for my Mac Book Pro notebook and proceeded to download the software, compile and test the installation of MySQL. I encountered a few issues after the installation was complete and there were related to DNS resolution and how MySQL resolves connection data.

What follows is brief narrative of my experience today installing MySQL from a Tar Package. Before beginning I will encourage anyone who is installing ANY software to make a current backup of their system. I’ve been using Time Machine for the past month and a half and I had one occasion where I actually recovered a preference file from my Time Machine backups. I generally use a combination of backup methods, I will use tar, Apple’s Backup Application, Apple’s Sync to backup preferences, bookmarks, etc. as well as Retrospect (EMC’s OS X Backup Solution, formerly owned and developed by Dantz). I’m not overly attached to any one backup solution and if you have the luxury, space, can afford external storage then Time Machine is not a bad solution. Time Machine offers very basic configuration options, essentially you turn it on or off and you can specify directories to exclude. It executes every hour and uses the Finder interface when you need to enter Time Machine to research and/or restore a file/directory previously backed up.

Prerequisites

You’ll need to install XCode which can be found on your Mac OS X Installation Media under the Optional Installs. You can also download the latest version of Apple’s Developer Tools (XCode) by creating an account on Apple’s Developer Connection website and navigating to Developer Tools then selecting the appropriate version for your system. A membership to ADC is free and the website URL is:

Existing MySQL Installations

If you already have a MySQL installation on your system you need to remove it or move it out of the way. Depending on whether it was installed from a Package or Source Code will determine how to remove the existing software. If it was installed from a Package then you can simply rename or delete a single file, actually the symbolic link in either /usr/local or /opt/local (the two most common locations for third-party or external software). By renaming or deleting the symbolic link you’ll disable that version from being at the minimal auto-started at boot time. If you choose to install or create your own Startup Item entry, you’ll want to remove that as well. Keep in mind that if you ever want to auto-start the old version of MySQL you’ll need to either re-download the package installer, reinstall the Startup Item(s) or copy/move them back into place.

Examples for renaming/deleting the Symbolic Link:

cd /usr/local
ls -l - you’ll see a directory entry with the name mysql -> if the links is present

sudo rm /usr/local/mysql – this will remove the symbolic link
sudo mv /usr/local/mysql /usr/local/mysql-oldversion – this will rename the link

To remove the previous installation:

cd /usr/local
rm -rf mysql

Exporting or migrating older data isn’t difficult but I’ll cover that topic in a different post.

Set Up Environment

To install the software you will need to open a Terminal Session, use an X11 Xterm session if desired or iTerm. The point is you will need to execute the commands using the Unix shell of your choice. It generally works best to pick a fixed size font for software installations to avoid discrepancies in typesetting, etc.

The first decision you need to make is where to put the new software installation. Most people choose either /usr/local or /opt/local. I believe the recent trend for OS X is to use /usr/local. It really is a user preference, however, most configuration defaults are geared to use /usr/local for the prefix. You can control that by passing the argument –prefix=/usr/local to the configuration script. For my install I choose /usr/local and that is what I will use here.

Set the Environment Variables

You can choose to either edit your .bashrc file at this time and just dynamically update your PATH variable. First, just check to see if /usr/local (or /opt/local) is in your PATH. You can do this by typing echo $PATH at the command prompt. If you do not see /usr/local in the PATH string you can add it by:

export PATH=$PATH:/usr/local:.

You can edit your .bashrc (assuming you are using the default OS X bash shell). Search for the location where PATH is defined and add /usr/local to the end of the string.

The second decision you need to make is where to put the tarball you will be downloading and what location will you use to compile and install from (this is just a scratch area). Typically, you already have a Downloads location specified in your FTP/SFTP tool of choice. I generally just expand the tarball in its download location, compile and install from there as well. Otherwise, you will need to make a directory to hold the source, objects and executable(s).

I’ll use /Users/auser for my example, where auser is the user who is currently logged into the operating system. Assuming auser has already defined a downloads directory named downloads there is nothing to create, we can start downloading the software.

Download, Extract, Compile, …

Now we are ready to begin the real work. Using the version information you discovered when researching the current stable release of MySQL above substitute that version in the below example:

cd $HOME/downloads
curl -O http://mysql.he.net/Downloads/MySQL-5.0/mysql-5.0.51.tar.gz
tar xvf mysql-5.0.51.tar.gz
cd mysql-5.0.51

Note: If you receive an error after you type in the curl command line most likely you do not have curl on your computer and you will need to download that software package before proceeding.

Next you’ll need to configure MySQL using the standard configuration script:

CC=gcc CFLAGS=”-03 -fno-omit-frame-pointer” CXX=gcc CXXFLAGS=”-03 -fno-omit-frame-pointer \
-felide-consructors -fno-exceptions -fno-rtti” \
./configure –prefix=/usr/local/mysql –with-extra-charsets=complex –enable-thread-safe-client \
–enable-local-infile –enable-shared

When the above process completes, you can then initiate the compilation process:

make

This part may take awhile, it depends on how fast of computer you have. The next step below is the step that actually installs the software in its final resting place which is the /usr/local/mysql directory structure.

sudo make install

You will most likely be prompted to enter in the administrative password for your machine.

Now that the software is in place you need to execute a couple of administrative tasks as well as scripts to populate the MySQL system tables, generate the root user and grant the basic security permissions and roles to the delivered MySQL user accounts.

cd /usr/local/mysql
sudo chown -R mysql ./var
chmod -R 777 /private/var/folders
sudo ./bin/mysql_install_db –user=mysql

That concludes the initial installation of MySQL.

Setting up Machine to Auto-Start MySQL

With the release of Leopard, OS X is strongly encouraging the use of launchctl to start processes at boot time. Other methods such as using the /Library/StartupItems directory to initiate processes during boot or system restart still work but the preferred method is to use launchctl.

One method to accomplish this is to create a plist file for MySQL and place it in /Library/LaunchDaemons. The following plist file was taken from Dan Benjamin’s blog on Installing MySQL on Mac OS X located at:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">
<dict>
    <key>KeepAlive</key>
    <true/>
    <key>Label</key>

    <string>com.mysql.mysqld</string>
    <key>Program</key>
    <string>/usr/local/mysql/bin/mysqld_safe</string>
    <key>RunAtLoad</key>

    <true/>
    <key>UserName</key>
    <string>mysql</string>
    <key>WorkingDirectory</key>

    <string>/usr/local/mysql</string>
</dict>
</plist>

Categories: Blogroll

Query Stuff

March 21, 2008 · Leave a Comment

PS Query Architecture Overview

Query and Timeout Analysis

Summary

This document provides an overview of the various timeouts that need to be considered when problems related to query occur. Before going into timeouts, an overview of the PeopleSoft Internet Architecture (PIA) follows to describe the information flow from the browser to the Database Server.

Overview of PeopleSoft Architecture

PeopleSoft Internet Architecture (PIA) is comprised of a variety of components ranging from the browser to the Database Server:

  • Web Browser
  • Web Server
  • Application Server
  • Batch Server – Process Scheduler
  • Database Server

The Web Browser is the primary means by which end users and administrators access PeopleSoft Applications and Administrative tools. PeopleSoft publishes Certification and Minimum Requirements for each PIA component including the end user workstation.

A Java-enabled Web Server is required to support browser transaction requests and the Application Messaging technology. A collection of Java Servlets are required to handle the wide range of PeopleSoft transactions. PeopleSoft publishes the minimum server requirements along with the certified web servers for each version of PeopleTools by Operating System and/or hardware platform.

The Application Server is the core of the PeopleSoft Internet Architecture, which issues SQL to the database server. It is responsible for maintaining the SQL connection to the database in order to service the browser requests. PeopleSoft publishes minimum server requirements for each version of PeopleTools by Operating System and hardware platform.

PeopleSoft uses Tuxedo to manage database transactions. Jolt, which is a Tuxedo communications protocol is used to facilitate requests from the end user workstation to the database via the Application Server. Tuxedo is a BEA product, BEA is now owned by Oracle as is PeopleSoft.

The Database Server houses the PeopleSoft database schema, which includes all of the object definitions, application tables and data. The database server simultaneously handles the application server connections, development environment connections as well as batch processing running against it.

The Batch Server is where the Process Scheduler is installed and configured and is responsible for servicing user submitted jobs as well as handling batch programs.

PeopleSoft Architecture – Information Flow
The Browser uses the HTTP protocol to send requests to the Web Server. A Servlet installed in the Web Server facilitates all browser connections. It relays transaction requests to the Application Server. Servlets are Java programs that run on the Web Server. If you choose to use Oracle Application Server as your web server the OC4J Containers perform this function.

Servlets on the Web Server transmit requests and data by way of communications to Jolt. Jolt runs on the Application Server. It is the communications layer between the web-based environment and the C++ environments. The Jolt Server Listener (JSL) routes the browser request to an available Jolt Server Handler (JSH) which passes the request onto the Application Server. The Application Server submits the appropriate SQL to execute against the database.

Any PIA or 3-tier request, which is service by the Application Server, is subject to certain timeout values, so that the system can control how much time is spent on servicing (processing) each request. One of the timeout settings that affects service execution is the Service Timeout value in psappsrv.cfg. For each type of server (PSAPPSRV, PSQRYSRV, PSQCKSRV, etc.) this value can be specified in the corresponding server’s section in the psappsrv.cfg configuration file for each Tuxedo Domain (Database Environment). If this setting is greater than 0 (in seconds), the service request will be terminated after it has been executing for the specified duration (i.e., the process which is servicing the request will be terminated by Tuxedo and a message will be written to corresponding Tuxedo log file). This setting affects both 3-tier and PIA requests. Another setting which affects the execution of PIA requests is the tuxedo_receive_timeout value in the Web Server’s pstools.properties file. When a PIA request is submitted, the Web Server waits for the duration of tuxedo_receive_timeout, and when this timeout value has been exceeded, it re-issues the request. If the 2nd request times out, an error is returned to the user (i.e., the Web Server can make up to a maximum of 2 attempts to service a PIA request, provided the first submission of the request times out or causes a service exception). If the tuxedo_receive_timeout is set to a value less than the server’s Service Timeout (in psappsrv.cfg), the Web Server will re-issue the request, although the original request may still be executing. This can be prevented by checking these configuration parameters and making sure they are working together.

Query Analysis

Now that the flow of information has been briefly summarized, we can continue the discussion by focusing on queries, since end users submit them quite often. Depending on the required information, queries are designed to return the result set of a SQL statement.

  • The PSAPPSRV, PSQCKSRV, and PSQRYSRV processes are basically the same program. They are named differently so they can handle specific types of requests (jobs) thereby dividing or distributing the load on the Tuxedo Domain.
  • If you choose to not configure and start the PSQRYSRV process, PSAPPSRV will take over PSQRYSRV’s job load, but that can result in slowing down overall performance. Keep in mind that if multiple queries are going to be executed by multiple end users the PSQRYSRV should be configured and used. During the configuration of the Tuxedo Domain you can specify that more than one (1) PSQRYSRV process is started. In fact you specify a minimum and maximum number of PSQRYSRV processes to initiate.
  • The PSQCKSRV process is used to service 2-tier and 3-tier PeopleTools processes. For example, if users will be using the PeopleTools Query program they will have the option of connecting to the database via either 2-tier or 3-tier mode depending on the PeopleTools Configuration Manager entries. If there will be users connecting via PeopleTools and they will be submitting queries then you should configure the psappsrv.cfg Application Server to start up a minimum and maximum number of these processes.

Common Client Issues

  • You may see that a query is submitted twice for each psqrysrv, for a long running query.

When any user initiates a long-running query, there is a possibility that the query may not complete within the service timeout set in the domain’s configuration file (psappsrv.cfg). As described earlier, this causes Tuxedo to terminate the PeopleSoft process, which is executing the long-running query. Although the PeopleSoft process has been instructed to die, they query may still be executing in the Database Server. As a result of the termination of the PeopleSoft process, the web server servlet, which submits the user request to the application server domain via Jolt, receives a Jolt exception and it will re-submit the request. Since the request may get submitted a second time, the database server will receive the same query again and the second request will execute in the Database server while the first request is still running. This can exasperate the original problem resulting in the failure (timeout) of both requests, creating server performance degradation, etc.

  • How do I control the time it takes to process the request as far as size of query is concerned?

Many times you will see that when a query is submitted, it processes for a long time. As a guideline, you can control the amount of data that a query can return by setting the Max Fetch Size parameter in the psappsrv.cfg file. This will cause the result set to be truncated at the limit specified in the configuration file and possibly result in reducing the overall processing time. It is better to not set this value to 0, to avoid any type of performance problems. However, be aware that the user community may not always receive complete result sets of their queries.

Example Settings for PSQRYSRV

; Settings for PSQRYSRV
;======================================================================
; UBBGEN settings
Min Instances=1
Max Instances=3
Service Timeout=1200

;————————————————————————
; Number of services after which PSQRYSRV will automatically restart.
; If the recycle count is set to zero, PSQRYSRV will never be recycled.
; The default value is zero.
Recycle Count=100000

;————————————————————————
; Number of consecutive service failures after which PSQRYSRV will
; automatically restart.
; If this is set to zero, PSQRYSRV will never be recycled.
; The default value is zero.
Allowed Consec Service Failures=2

; Max Fetch Size — max result set size in KB for a SELECT query
; Default is 100000KB. Use 0 for no limit.
Max Fetch Size=10000

  • The query continues to execute in the database, even when it is not running on the application server side.

As explained above in the first point, even though a PeopleSoft process is terminated, they query may still continue to execute in the database (i.e., there is no way for a terminated process to clean up the request that is submitted to the database). Oracle has a workaround to find out if the parent process exists or not. This workaround helps to find out if the parent process is dead; if so, it terminates the child process also. However, it is possible for the Oracle process executing the query submitted via the application server to become orphaned. In those cases it is best to check with the PeopleSoft DBA and have them investigate and terminate the orphaned query process if it can be identified.

Database Timeout

Due to the possibility of a PeopleSoft process service timeout and the consequent resubmission of the request by the Web Server, a query may get submitted to the Database Server more than once. The options for dealing with a long-running or runaway query in the Database Server are:

  1. Kill the database thread/process which is executing the query in question.
  2. Apply the dead connection detection mechanism.

Refer to the following resolutions in Customer Connection:

#200728668: Managing Long running queries after the Server has been terminated

ISSUE: Queries continue to run in my database after the Server (PSAPPSRV, PSQRYSRV) have been terminated. How can I clean these up?

RESOLUTION: I’m afraid that once the PSAPPSRV or PSQRYSRV is terminated due to a Service Time-out, there is not much PeopleSoft can do to kill the query thread in the database. Oracle though has a mechanism for determing if a thread has an active parent or if the parent is no longer alive.

On the Database side one needs to create a SQLNET.ora file in the directory $ORACLE_HOME/network/admin. Add the following parameter to the SQLNET.ora file:

sqlnet.expire_time=10

Please Contact Oracle for information regarding their “Dead Connection Detection Mechanism” or use MetaLink to look this information up. A little bit of the description of this mechanism follows.

DEAD CONNECTION MECHANISM

Dead Connection Detection (DCD) is a feature of SQL*Net 2.1 and later, including Net8. It detects when a partner in a SQL*Net V2 client/server or server/server connection has terminated unexpectedly, and releases the resources associated with it.

DCD is intended primarily for environments in which clients power down their systems without disconnecting from their Oracle sessions, a problem characteristic of networks with PC clients.

DCD is initiated on the server when a connection is established. At this time SQL*Net reads the SQL*Net parameter file and sets a timer to generate an alarm. The timer interval is set by providing a non-zero value in minutes for the SQLNET.EXPIRE_TIME parameter in the sqlnet.ora file.

When the timer expires, SQL*Net on the server sends a “probe” packet to the client. (In the case of a database link, the destination of the link constitutes the server side of the connection.) The probe is essentially an empty SQL*Net packet and does not represent any form of SQL*Net level data, but it creates data traffic on the underlying protocol.

If the client end of the connection is still active, the probe is discarded, and the timer mechanism is reset. If the client has terminated abnormally, the server will receive an error from the send call issued for the probe, and SQL*Net on the server will signal the operating system to release the connection’s resources.

On Unix Servers the sqlnet.ora file must be in either $TNS_ADMIN or $ORACLE_HOME/network/admin. Neither /etc nor /var/opt/oracle alone is valid.

It should be also noted that in SQL*Net 2.1.x, an active orphan process (one processing a query, for example) will not be killed until the query completes. In SQL*Net 2.2, orphaned resources will be released regardless of activity.

This is a server feature only. The client may be running any supported SQL*Net V2 release.

THE FUNCTION OF THE PROTOCOL STACK
———————————-

While Dead Connection Detection is set at the SQL*Net level, it relies heavily on the underlying protocol stack for its successful execution. For example, you might set SQLNET.EXPIRE_TIME=1 in the sqlnet.ora file, but it is unlikely that an orphaned process will be cleaned up immediately upon expiration of that interval.

#38704- Database keeps working on transaction after Application Server process times out

ISSUE: Customer set timeouts for Tuxedo appropriately, and can see that Tuxedo is indeed killing the process that is servicing the service request. However, the database does not seem to realize that the connection was severed and therefore keeps eating up CPU time.

RESOLUTION: This depends on the type of database server used.

Oracle: A dead connection timeout value needs to be defined in the sqlnet.ora file on the database server. This parameter is SQLNET.EXPIRE_TIME = M where M is a value in minutes. Oracle recommends setting this value to 10. When that time is reached, the database system will ping the client–who is in this case a program servicing a Tuxedo service request, and when this timeout hits, if the connection is down, the transaction will be stopped and rolled back. This means: if the client is busy, nothing will happen. If the client is NOT busy, the transaction will be cleaned up. If you are using a BEQ (BEQ) then this setting will not work. You are using a BEQ connection if in your application server domain’s psappsrv.cfg file you have UseLocalOracleDB=1. You must use either TCP and IPC connections for this setting to take effect.

Informix: There is also a similar timeout, but this is non-configurable and set to 10 or 15 seconds.

DB2: There is a “unit of work timeout” on the database engine. By having the DBA set this value, you can get timeouts to take place shortly after the remote call timeout from Tuxedo.

Note: For PeopleTools 8.44
============================================================================================
There is a new featured introduced in 8.44 called Query Kill. Users should be able to kill long running queries by navigating to PeopleTools->Utilities->Administration->Query Administration. On the execution tab they can search for long running queries and then choose the Kill Selected Query button. It should kill the PSAPPSRV or PSQRYSRV process that is associated with that query, delete the row from PSQRYTRANS and stop it at the db level as well.

-For PeopleTools 8.44 and above, also review the document KillQueryWord.doc

-PSMONITORSRV process cannot be turned off because it serves two functions: The first is to report host / domain resource information to Performance Monitor. The second is to support canceling a PeopleSoft Query in PT 8.44.

If the timeout occurs on the Database Server when the Application Server process is still waiting for the query execution to be completed, the DB client will return an appropriate error code to the Application Server process. The appsrv.log can show this error code. Similarly, when a service timeout occurs, the Web Server gets a Jolt Exception.

Note: Incident T-MJOHNS-YB7FA was reported for this problem. It is resolved in Tools 8.21 and 8.44.

Application Server Timeout

Service Timeout specifies the number of seconds Tuxedo waits for a service request, such as MgrGetObj or PprLoad, to complete before terminating it. The psappsrv.cfg file in $PS_HOME/appserv/ contains 1 Service Timeout value per server. If needed, you can increase the Service Timeout value for PSAPPSRV. This requires reconfiguring the domain after changing the Service Timeout value in psappsrv.cfg and then restarting your Application Server processes via psadmin. Here’s an example of psappsrv.cfg:

[PSAPPSRV]
; Settings for PSAPPSRV
; UBBGEN settings
Min Instances=3
Max Instances=3
Service Timeout=300

If the Service Timeout is set to 0, the request can run endlessly (it is a good idea to set this parameter to a high value rather than never letting it time out). However, a PIA request may still be subject to the tuxedo_receive_timeout on the Web Server. Service Timeouts are recorded in the TUXLOG.LOG and APPSRV.LOG. In the event of a timeout for a PSAPPSRV process, it is killed by Tuxedo. If the domain setting “Restartable” is set to Y in psappsrv.cfg, Tuxedo automatically starts another instance of the same server process to replace the killed one. TUXLOG registers the timeout message as show below:

Web Server Timeout

If an Application Server process dies because of any reason other than a service timeout or a database timeout, the servlet behavior should be analyzed. You may see that it resends the same request one more time. As mentioned previously, this is by design.

PeopleSoft recommends keeping the tuxedo_receive_timeout value higher than or equal to the service timeout value for the Application Server processes.

tuxedo_receive_timeout is the servlet timeout value in the pstools.properties file. For example, on Windows, it is located in weblogic\myserver\psftdocs\peoplesoft (WebLogic 5.10) or bea\weblogic6.1\config\peoplesoft\applications\portal\web\psftdocs\ps (WebLogic 6.1). It is set to 600 (10 minutes) by default. Here’s an example of pstools.properties:

# Tuxedo parameter settings
# default is disconnect=0, send=10, receive=10
tuxedo_network_disconnect_timeout=0
tuxedo_send_timeout=50
tuxedo_receive_timeout=600

There are 6 main parts to the query kill and timeout functionality. First, is the new PSQRYTRANS table. Every time a query is run from Query Manager or Query Viewer a row is written to this table.

Second, are changes to the Query Administrator that displays the queries that are
being run from Query Manager or Query Viewer – i.e., rows in PSQRYTRANS – there are a number of options here. This page will also provide the ability to mark a row to be killed by the system.

Third, are changes in the page to manage permission lists. A new field has been added here that represents the number of minutes that a query can run before being timed out. The number 0 represents an infinite timeout value. The query timeout vale that is used is the greatest number, or 0 if it exists, for all permissions lists of all roles that a user belongs to.

Fourth, is the QRYTIMEOUT flag in the PSQRYFLAGS table. This is a global flag that controls the enabling of the query timeout functionality.

Fifth, is the query monitor. This is an appserver function that is run every minute that looks for queries that have reached their time limit, or have been marked to be killed. It will also check for orphaned rows – ie. rows that have no timeout, and the appserver process doesn’t exist or isn’t running a query. Also, as it finds a row to kill or timeout it will ensure that the process is really a PSAPPSRV or PSQRYSRV that is running a query.

Sixth, when a query is killed we will increment a new field, NUMKILLS, in PSQRYSTATS. This is also reflected in the query stats GUI. We will also write a row in PSQRYEXECLOG. There is a new field, in this table – KILLEDREASON – that reflects why the query was killed. “T” for timed out, “K” for killed. The only other field that is updated in the row is EXECDTTM, which is set to the time the query was killed. This is also reflected in the exec log GUI.

Tests to Run:
In order to test various cases:

  • There are 4 distinct ways that a query can be started: query viewer, run to HTML from Query Manager, run to file from Query Manager and Preview from Query Manager. We need to make sure that a row is correctly written to PSQRYTRANS for each of these cases.
  • Note:All 4 methods do not share a common mechanism – Preview uses the Query API and the rest use the ICQuery Service.The ICQuery Service can run on either PSAPPSRV or PSQRYSRV, but both of these share the same code so we don’t need to test both process types.
  • Make a query (row) for kill from the Query Administrator Page, and ensure that it is killed within approximately 1 minute.
  • Setup and ensure that a query times out and is killed within approximately 1 minute of its timeout value.
  • Check that the correct timeout is used when different timeout values are in multiple permission lists. When various numbers exist it uses the greatest value, when various numbers exist and if a zero exists it uses an infinite timeout.
  • Ensure that the global timeout enable/disable functions by setting it through ???. Ensure that a row is still written to PSQRYTRANS when this is disabled.
  • Ensure that the number of times a query is killed is reflected in the query stats GUI.
  • Ensure that a row is written in the Query Exec Table. Also, need to ensure that the time the Query is killed is recorded in EXECDTTM, and the correct reason “K” or “T” is written to KILLEDREASON.
  • Ensure that the Query Administrator (executing page) will display all running queries for the various options – all running queries, running queries by name and queries running for nn minutes.

If there is enough time for testing then you should also look into testing these cases:

  • Ensure that the Query Monitor cleans up orphaned rows.
  • Ensure that the Query Monitor will not kill a process that is running something else – i.e. the Process ID in the row can’t be the Process ID for another process other than PSAPPSRV or PSQRYSRV. Also, make sure that if the Process ID points to a PSAPPSRV or PSQRYSRV that is running a different operation it doesn’t kill it.
  • Ensure that one domain’s Query Monitor does not try to do anything with queries from another Domain.
  • Ensure that rows are not written to PSQRYTRANS from the Query API when it is called from something other than Query Manager and Query Viewer.

Categories: Blogroll

TREENAME is Undefined, Inactive or Invalid

March 5, 2008 · 1 Comment

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 .

Categories: Blogroll

How To Run Tree Utility Tree Audit

March 5, 2008 · Leave a Comment

How to run the Tree Utility Tree Audit to check for Tree Corruption

There is an Application Engine program that you can run that can check for tree
corruption.  The navigation to get to the Tree Utility Tree Audit is through the
browser:

8.1x:  PeopleTools>Tree Manager>Process>Tree Utilities. 
8.4x:  PeopleTools>Tree Manager>Tree Auditor

Users will then need to create a run control id.  The default will be set to
‘Tree Utilities’.  There is a checkbox for ‘all trees’.  If this box is checked,
then the tree audit will check all the trees for tree corruption.  This would be
good to use just for regular tree maintenance, but to check for a specific tree,
you can input the tree name, tree key, and effective date. 

After the process is run, go to the Process Monitor to verify that it went to
success.  From Process Monitor you can click on a link that will take you back
to the Tree utilities.  From the Tree Utilities page you can click on the
‘View Results’ link.  In there it will give you the results of the Tree Audits.

Categories: Blogroll

Tree Utility Audits Check What?

March 5, 2008 · 1 Comment

What does the Tree Utility tree Audits through the web check for?

In PeopleTools 8.1x there is a new tree utility program that will audit the trees.
What does this check for?

This tree audit will check for trees with the following:
1)  Parent node does not exist
2)  Orphan tree leaves
3)  Tree Node Numbers are great than end numbers
4)  Tree node’s end number is greater than parent’s end number
5)  Tree nodes with overlapping ranges
6)  Node’s level number is less than parent’s level number

How to fix:

  1. Parent Node does not exist: If there are no other audit errors for this tree
    then running the ‘Correct Parent Node’ Utility program should correct the problem. Do NOT run the ‘Correct Parent Node’ Utility program if there are any other audit problems with the tree.  The other errors should be addressed first before trying to correct problems by running the utility program.
  2. Orphan Tree Leaves: There are records in the PSTREELEAF table where the leaf’s parent node number does not have a correspondnig record and node number in the PSTREENODE table.  Run the ‘Delete Orphan Tree Objects’ utility to delete these records
  3. Tree Node Numbers are Greater than End Number: Tree Nodes that have node numbers greater than the ending range for that node. The only solution is to use TreeManager to delete these nodes and then run the ‘Reset Tree Node Gaps’ utility program.  You will then need to re-insert the deleted nodes.  If for some reason you are not able to delete these nodes from within TreeManager it is recommended that you call the GSC for support.
  4. Tree Node’s End Number is Greater than Parent’s End Number: This audit reports on tree nodes whose end range value is greater than the end range value of its parent node. The only solution is to use TreeManager to delete these nodes and then run the ‘Reset Tree Node Gaps’ utility program.  You will then need to use Tree Manager to re-insert the deleted nodes.  If for some reason you are not able to delete these nodes from within TreeManager it is recommended that you call the GSC for support.
  5. Tree Nodes with Overlapping Ranges: Two nodes that have overlapping node number ranges. The only solution is to use TreeManager to delete these nodes.  If for some reason you are not able to delete these nodes from within Tree Managerit is recommended that you call the GSC for support.
  6. Node’s Level Number is Less than Parent’s Level Number: Nodes whose level number is less than the level number of their parent.
  7. The level numbers can be corrected by either: Switching the levels manually from within Tree Manager. Run the ‘Correct Level Numbers’ utility to reset all invalid level numbers on the tree.

Categories: Blogroll

How to Get Custom Queries from Production Database

March 5, 2008 · Leave a Comment

What are the steps to get current custom queries from Production database?

In order to get a copy of your queries, you should perform the following steps:

  1. Obtain a list of queries, trees, and tree structures that you need to preserve.
  2. At the beginning of the test Move to Production, you should make a new
    copy of your current production database (I’ll refer it as “Tree/Query Copy
    of Production”). Now you should have a Copy of Production database and a
    Tree/Query Copy of Production database.
  3. Perform the test Move to Production on your Copy of Production database.
    (NOT on your “Tree/Query Copy of Production”).
  4. The Tree/Query Copy of Production database needs to be at the same
    release level as the Copy of Production database on which you just completed
    the test Move to Production. To update your Tree/Query Copy of Production to
    the same release, you run release scripts against this database. PeopleSoft
    refers to this as “reling up” the database. Use the Custom Compare template
    to “rel up” your database. Select the Product Line PEOPLETOOLS when
    configuring your Change Assistant job. Perform all the steps in the template.
  5. Create a project in the Tree/Query Copy of Production that contains all
    of the queries and trees that you wish to preserve called PRESERVED.
    Manually compare the queries, trees, and tree structures that are in your
    PRESERVED project against your Copy of Production database.
  6. Copy the PRESERVED project to the target database (Copy of Production
    database on which you ran the test Move to Production). 
  7. Queries, trees, and tree structures that you wanted to preserve should
    be in the Copy of Production database now. You must test and re-test and
    make any necessary changes if the test results are not what you expected.
  8. Once you are satisfied with the test results, you must re-export the
    PeopleTools tables from the Tree/Query Copy of Production using MVPRDEXP.DMS
    in order to actually preserve the queries, trees, and tree structures. You
    will now use the output files created from running this script as input files
    during your final Move to Production. Running the MVPRDEXP.DMS script again
    ensures that you have the most current PeopleTools tables that include your
    preserved custom queries, trees, and tree structures.

Find details on how to run each of the steps above in the appendix Queries Trees
and Tree Structures of your upgrade documentation.

Categories: PeopleSoft · PeopleSoft Query · PeopleTools

nVision Tree Undefined, Inactive or Invalid

March 5, 2008 · Leave a Comment

E-NV:  Error running nvision ‘Tree undefined, inactive or invalid’

SOLUTION 200993098:  E-NV:  Error running nvision ‘Tree undefined, inactive or
invalid’

SPECIFIC TO:
Enterprise, PeopleTools, nVision, All PeopleTools versions

ISSUE: Running nVision report gives an error that the tree is undefined, inactive,
or invalid.  Checks and the tree exists and is valid. 

SOLUTION:
This error is generally caused by the business unit being used for the nVision
report not having the default setid of the tree being used.  The first thing to
check is the table set tree controls:

PeopleTools -> Utilities -> Administration -> Table Set Controls
Look for the Business Unit that you are using in your nVision report.
Go to the tree tab and see if the default SETID is the setid of the tree that
you are using.  If it is not, then add the tree to the bottom area there.  (Even if it is already the default, try adding it and see if it makes a difference).

NOTE:  When adding a tree to the tableset tree controls, you need to
first use the lookup for the SETID and then the lookup for the tree name. 
It looks backwards.

Categories: Blogroll