Minimum Files Needed for PeopleTools Client Installation

When installing PeopleTools on a local workstation, you don’t actually need to copy the entire PeopleTools folder to the user’s hard drive. This would involve copying in excess of 6GB of data (PeopleTools 8.52.06). Copying such a large amount of data across a network can be problematic in that it will take several hours, and sometimes fail, especially is your user is remote. The minimum files to successfully run PeopleTools locally is a little over 2GB total, a much more manageable amount of data.

The following folders are the minimum you require to successfully run PeopleTools from a local client: appserv, bin, excel, nVision, setup, and tuxedo.

Please note that you can also reduce the data size greatly by only copying the English language versions of the nVision macro files (or the appropriate local language folder if your users are working in another language). So for example, if you are an English-language site, delete all the folders found under the Excel folder with the exception of the stylesheets folder. If you users are running nVision in one of the other languages, copy and replace the files in the local language folder to the root of the Excel folder.

Interface Exception Error gridapp.ccp:1828

Problem Statement

Excel interface exception error gridapp.ccp:1828 SCODE = 0X80010001 is issued when a user attempts to close an nVision instance, drilldown, or other Excel workbook

Root Cause

Excel Interface Exception Errors are unfortunately a part of life with nVision. The messages given with them are often cryptic and no help at all in identifying the cause. 

After extensive testing I have identified that this error occurs under the following circumstances (I have reported this issue to Oracle Support SR #3-5976739951):

  • The user has a large number of Excel files open (typically around 30+ files)
  • The user attempts to close an Excel file from the file stack in the Excel Taskbar group, and importantly, the file they attempt to close has unsaved changes. The error occurs whether the user uses the X available in Excel 2010, or by right-clicking and selecting close in either Excel 2010 or Excel 2007. The error is issued with the Save dialog.

Note: The issue occurs frequently for our user community because many layouts select actuals and translate ledger data side by side and then sum them to the right. The ledger data columns are hidden using Excel grouping. To perform drilldowns on the ledger data, the users have to expand the grouping which places the instance into a "changed state" that Excel will issue a save dialog for when the user comes to close it.
We are running on Tools 8.52.06. I have replicated this error on both Windows 7 with Excel 2010, and Windows XP with Excel 2007. I have also been able to replicate the error in Tools 8.52.06 DMO. I have an SR open with Oracle on this issue which appears to be some kind of bug. 

Different error messages are issued once the user interacts with the Save dialog box. 

If the user clicks Yes to save the file, they are presented with a suggested file name of :.xlsx. This is an illegal name for Windows. Saving the file with an appropriate name results in errors that refer to Excel 4.0 Functions and Excel 4.0 Macros.

Excel 4.0 Function / Excel 4.0 Macro cannot be saved in a macro-free workbook

At this point the user finds themselves in a loop with a macro error being issued no matter what action they take. The best way to escape is to use Task Manager to close nVision and Excel.

Clicking No to the save dialog issues an error "Cannot run the macro 'NvdOnWindow'". The user is once again locked in a loop.


We are currently testing the following workaround
  • Do not close files from the Excel group stack in the Taskbar. Rather, select the file you wish to close from the stack, and with that file active, close it from the workbook itself.

Cannot run the macro ‘NvdOnWindow’

Problem Statement

While running nVision reports and drilldowns in 3-tier, when the user attempts to close the parent report instance, they are prompted to save the file even though they have not made any changes to it, and receive an Excel interface exception error:

Excel interface exception SCODE = 0x80010001 error for PeopleSoft nVision Designer (28,160)

When the user clicks Don't Save, they receive the following error

Cannot run the macro 'NvdOnWindow'. The macro may not be available in this workbook or all macros may be disabled. (The user's macro setting is to low: "Enable all macros".

If the user clicks Yes to save the file, the Save As file name is :.xlsx. After substituting acceptable characters for the colon, the user receives the following errors:

Errors were detected while saving 'file path'. Microsoft Excel may be able to save the file by removing or repairing some features. To make the repairs in a new file, click Continue. To cancel saving the file, click Cancel.

Upon clicking Continue, the user receives the following error messages:

The following features cannot be saved in macro-free workbooks:
-          Excel 4.0 function stored in defined names
-          Excel 4.0 Macro Sheets (these will be converted to normal worksheets)


Replication of the issue ultimately identified the issue occurred when using a customized Journal Lines drilldown layout.

Forensics indicated that the layout had been cloned, most likely from the delivered JrnlLayout.xnv, and that it had likely been created in Excel 4.

The following points of interest were noted:

-          The setid had not been specified in the Layout Options indicating copying and pasting layout criteria
-          Three defined names in the workbook are not names that are added to layouts with current nVision releases
o   NvsDateToNumber
o   NvsInstCritOpt
o   NvsUpdateOption

I attempted to resolve the issue by making the following changes:
-          Removing the above three highlighted names
-          Specifying SHARE as the default setid under the nVision Layout Options

However, the issue persisted despite these changes.

I then resorted to recreating the drilldown layout from scratch.

Using this new drilldown layout resolved the issue.

Putting together a few hunches, it seems that some layouts that we have date back to Excel 4 based on the error messages. Macros moved to VBA with Excel 5 which came out in 1993. Since Excel 2007, the entire architecture of Excel has changed and it seems that some layouts, this journal lines drilldown layout being one of them, inherited "bad genes" along the way. 

If you are receiving "macro not found" or "macro not accesible" errors like this, you may need to recreate the layout from scratch, particularly if it is a layout that has been upgraded from an early version of Excel (particularly Excel 4 and below) to a new version of Excel.

Client Cleanup Timeout - nVision Not Responding

Problem Statement

After leaving their 3-tier nVision session idle for 60 minutes, when the user returns to use nVision, there is a delay while nVision appears to reconnect to the database. At the top of the nVision program, it says “Not Responding”.


There is a setting in the Application Server configuration file that specifies the timeout for 3-tier connections. This is designed to release allocated resources when users’ 3-tier sessions have been left idle. The delivered default setting is 60 minutes.

If this timeout is frustrating your users, and your App Server resources are not overtaxed, here is how to set the Client Cleanup Timeout to zero (i.e. never timeout):

Set "Client Cleanup Timeout" to ZERO for Workstation Listener & re-load application server domain configuration.


[Workstation Listener]
; Settings for Workstation Listener
Min Handlers=5
Max Handlers=12
Max Clients per Handler=40
Client Cleanup Timeout=0

Running PeopleTools Uninstall from the Run Prompt

Problem Statement

The user’s PeopleTools client installation was done without the Uninstall Workstation selected. I now need to uninstall nVision but the Uninstall Workstation shortcut is missing.


Here’s how you can run PeopleTools Uninstall Workstation in such cases:

·         Start a run prompt by typing Windows + R

·         Type the path for the location of the Config Manager executable that the user’s client installation is using and then type a space followed by –clean, and click OK

·         You will now be presented with the Uninstall Workstation dialog


nVision Start-Up and Shut-Down Best Practices

Start Up

Best Practice

Close any current sessions of Excel before launching the nVision signon dialog

Many users of nVision are frequent users of Excel for their job responsibilities and will start nVision when Excel has already been started for other job functions. At startup, nVision initiates its own instance of Excel that is separate from the session that is already running, as can be illustrated in the screen shot from Task Manager:

Consequences of multiple Excel Instances

·         After completing the signon dialog for nVision, nVision fails to start up
·         As the user jumps unknowingly from one Excel instance to the other, conflicts can arise that result in  cryptic “Excel Interface Exception errors”


  • Close any and all instances of Excel and nVision
  • Start Task Manager, sort “Image Name” on the Processes tab, and end any and all instances of EXCEL.EXE and psnvs.exe
  • Restart nVision

Shut Down

Best Practice

Close nVision from the nVision program, not from Excel

Consequences of incorrect shutdown

Incorrect shutdown of nVision can result in hung sessions of Excel and/or nVision in Task Manager which are not obvious to the user since no program icon is displayed in the user’s Task Bar. This can result in nVision not starting up the next time the user attempts to start nVision as described above.


·       Close nVision by clicking on the nVision icon in the Task Bar and either navigating to File > Exit or by clicking the X as illustrated below

nVision Fails to Start

Problem Statement

2- or 3-Tier user starts the nVision logon dialog and enters their credentials, but nVision doesn't start up.


This issue can be the result of bad nVision shut-down practices that result in hung Excel and nVision processes in Task Manager.

Users should shut down nVision by clicking the nVision program icon in the their taskbar and either clicking File > Exit or by clicking the red X in the top right corner. This should close nVision and Excel cleanly.

However, many users exit nVision by exiting from Excel. This can result in Excel and nVision processes becoming hung in Task Manager.

To check for hung instances of Excel and/or nVision, make sure Excel is not running and the nVision logon dialog is closed, then go to Task Manager. (Did you know that the keyboard shortcut for Task Manager is Ctrl+Shift_Esc).

On the Processes tab click Image Name twice to sort running processes in ascending alphabetical order. If you see EXCEL.EXE and/or psnvs.exe in the list, click on the row and then click the End Process button in the lower right. (Note: can also be done by right-clicking and selecting End Process from the pop-up menu).

Repeat until there are no more instances of Excel or nVision running - sometimes there can be multiple instances of Excel or nVision hung up.

Ask the user to attempt logging in to nVision again. All going well, nVision should now start cleanly for them.

Excel interface exception cannot access the file gridapp.cpp:2518

Problem Statement

When a user runs an nVision report in 2- or 3-tier, the report appears to run ok, but at the end the user receives the following error messages and after they click through the error messages the report instance is lost.

'Excel interface exception [E:\pt<your PeopleTools Release Number>b-retail\peopletools\src\psnxl\gridapp.cpp:2518] Microsoft Excel cannot access the file '\\<your save to location path>\YourReportFileName.xlsx'.
There are several possible reasons:
• The file name or path does not exist.
• The file is being used by another program.
• The workbook you are trying to save has the same name as a currently open workbook.' Error for 'Microsoft Excel: '. (28,160)

An interface error has occurred while trying to read or write information to Excel. This message is most likely an error that was generated by Excel where the string above contains the information passed back by Excel for the location given.

Variable <your save to location path>[= '<your save to location path>\YourReportFileName.xlsx'] is invalid for document templates. (28,32)

Root Cause

Whenever an nVision report is run, after the data has been extracted and placed into Excel, the instance is saved by Excel. The location the report is saved to is determined by what is in the the Directory Template field on the report request. (If it is blank, it is determined by what is in the user's configuration file). If the location is a shared folder on a network, then you can get this error which indicates that you are running a report to a shared network location and that another user has also run the same report ahead of you with the exact same name, and they still has the report instance open. Windows will therefore not allow you to save the file.

Typcially this issue will occur when the File Template has a variable in it that resolves the "as of date", and you are running the report for the same as of date as the other user.


  • If you happen to know who has the file open, you can ask them to close the file if they are no longer working with it
  • If they are still working with it, on the report request you can change the output destination ("Directory Template") to a new location (Important: Do not save the change to the report request if the change should not be saved to the database - when running nVision in 2- or 3-tier, changes made to the Report Request are reflected when the report is run without having to save the changes)
  • Blank out the information in the Directory Template and rerun the report. This will save the report to the default specified in the user's configuration file. The PeopleSoft "standard" for this is C:\nvision\instance, but may be something different depending on your company's standards. (Once again, do not save your change if the change to the report request should not be saved to the database)
  • If you need the report output to be saved to the same network location and the report is against the LEDGER table as are most nVision reports, then a workaround is to change the "as of date" for the report to another date within the same accounting period. You will still get the same data on your report because there is no specific accounting date on the ledger table; the data on the ledger table is summarized by Accounting Period. For example, if your fiscal year is December, then any "as of date" between 01/01/YYYY and 01/31/YYYY will return the same Accounting Period 1 data from the ledger table. (Important: If you have "as of date" information in your report header, bear in mind that if you are sharing the report with others, unless you manually change the date in the report header to the last day of the period, they may fear that the data is not complete. The as of date you run the report for will also be reflected in the file name if the "%ASD%" variable is part of the File Template).

Excel Formulas Not Calculating

Problem Statement

Some formulas on an nVision instance using Excel 2010 are not being calculated when the report is run. Calculation Options are set to "Automatic" so all formulas should be calculating. Recalculating the spreadsheet using F9 does not resolve the issue.

This issue started to happen on some reports, but not all, once the users had been upgraded to Excel 2010 on Windows 7 machines. It occured with PeopleTools 8.51 running in Excel compatibility mode with layouts created in Excel 2003 and below, and also after upgrading to PeopleTools 8.52 with the layout upgraded to Excel 2010.

My research online indicates that this issue sometimes occures with Excel 2010 when the spreadsheet was first created in "legacy" Excel (Excel 2003 and below). All longtime users of PeopleSoft nVision will be in this situation. The issue is an Excel 2010 issue, not an nVision issue per se.


I discovered that when I changed the formulas from addition formulas using + to forumauls that used SUM this resolved the issue. For some unknown reason, once I did this, all the addition formulas across the rows to the right of the formulas I updated that weren't calculating before, now caclulated fine without having to change them. I had to change all formulas down the entire first column in all the rows where the issue was occuring.

Workaround / Quick Fix

  •  If your layouts have not yet been upgraded from old Excel (Excel 2003 and below - .xls nVision instance files), then once the report instance has been generated, "converting" the instance to Excel 2010 results in all formulas being calculated correctly.

    To convert the instance from .xls to .xlsx (or .xlsm if there is a macro attached to your layout), navigate to File and click the Convert icon.
Convert old Excel format to Excel 2010 format by clicking the Convert icon under the File > Info menu
  • Many of you will know that if auto-calculation has been disabled, you can recalc your spreadsheet by typing F9. However, F9 only recalculates formulas that have changed, or for which the data in dependent cells has changed since the last time the spreadsheet was calculated. That being the case, F9 will not resolve this issue.

    However, Ctrl + Alt + F9 recalculates all forumulas whether they have changed or not. I found that this resolved the issue.

nVision Layout Directory registry setting missing or invalid

Problem Statement:

When a user starts nVision in 2- or 3-tier, they receive the following warning:

The PS/nVision LayoutDir registry setting is missing or invalid. Yes to continue. (28,154)

Layout Directory Setting Missing or Invalid Warning

 Root Cause:

This issue occurs if you have a back-slash (\) at the end of the layout directory path in the user's configuration file.


Start Configuration Manager on the user's machine.

Note: If there is no shortcut to Config Manger on the user's desktop or Windows Start Menu, the Config Manager file is located at the User'sPeopleTools Installation location\bin\client\winx86\pscfg.exe)

Remove the back-slash at the end of the Report Layouts path:

nVision Configuration Manager Report Layout Directory

nVision DrillDown Directory Registry Setting Missing or Invalid

Problem Statement:

When a user starts nVision in 2- or 3-tier, they receive the following warning:

The PS/nVision DrillDownDir registry setting is missing or invalid.  Yes to continue. (28,154)

Root Cause:

This issue occurs if you have a back-slash (\) at the end of the drilldown directory path in user's configuration file.


Start Configuration Manager on the user's machine.

Note: If there is no shortcut to Config Manger on the user's desktop or Windows Start Menu, the Config Manager file is located at the User'sPeopleTools Installation location\bin\client\winx86\pscfg.exe)

Remove the back-slash at the end of the drilldown layouts path:

How to Upgrade an Old nVision Layout to Excel 2010

  1. Start nVision in 3-tier (your current 8.51 PeopleTools version)
  2. Open your layout from nVision.
  3. Click File at the top left of your menu bar and then click the “Convert” button as illustrated. (Note, if this is a newish layout that you created in Excel 2007 or 2010, you will not see the Convert button and no action is needed – the layout is already in the new Excel architecture.)

  4. Let Excel "do its thing" and just click the Save button when you get the save dialog box. Note that the file extension will be either xlsx or xlsm, depending on whether or not your layout has a macro attached.

    You will next be prompted by Excel to close and reopen the file. Click Yes to complete the conversion.
    Close the file. (Save if prompted).
  5. Go to your nVision folder location and sort files by name. You will see your layout file and a new xlsx or xlsm file next to each other.

    Delete the old xnv file, and then change the file extension for the xlsx or xlsm file to xnv.

    Your layout upgrade is now completed and ready for prime time!

Which PeopleTools Release Supports Excel 2007/2010

Oracle did not do such a good job with releasing nVision that was fully-compliant with the architecture of Excel 2007 and 2010.

When we upgraded to PeopleTools 8.51.11 in November of 2011, we had to go live with all the layouts still in old Excel architecture running in compatibility mode. When we initially tried using upgraded layouts the users had no end of trouble running the reports.

In April 2012, we upgraded to PeopleTools 8.52.06 and finally we have been able to run nVision with upgraded layouts without any issues.

I'm not exactly sure which sub-release of Tools 8.52 fixed all the issues, to go for 8.52.06 or above if you can.