Casey - Thanks for checking, that behavior makes sense given your findings that one particular row skips your clean up of PS_PTUPGDDDOUTPUT.

To further explain INVWBUSY row (DDDTYPE = INVWBUSY, PTP_SEQ_CHAR = V-1) is a temporary “busy flag” record used by the upgrade SQRs (like DDDINVWS.SQR) to prevent concurrent access to PS_PTUPGDDDOUTPUT. It should normally be deleted automatically at the end of a clean run, but if the previous DDDAudit or Invalid View step was interrupted or failed mid-process, the flag can remain in the table.

Snippet from dddinvws.sqc

begin-SELECT

'Y' &SelIsBusy1

FROM PS_PTUPGDDDOUTPUT

WHERE DDDTYPE = 'INVWBUSY' OR DDDTYPE = 'DDDBUSY'

end-select
…..
…..
…..

if $Skip_db_insert_delete = 'N'

begin-SQL on-Error=Rpt-SQL-Error

DELETE FROM PS_PTUPGDDDOUTPUT WHERE DDDTYPE = 'DDDINVWS'

end-SQL

do Commit-Transaction

end-if

Before rerunning the upgrade (or cloning Prod for a fresh run), it’s safe and recommended to run below.

DELETE FROM PS_PTUPGDDDOUTPUT WHERE DDDTYPE IN ('INVWBUSY','DDDBUSY');
DELETE FROM PS_PTUPGDDDOUTPUT WHERE DDDTYPE = 'DDDINVWS';

This ensures the invalid-view audit starts clean and doesn’t reuse stale or half-processed data from an earlier run.

You don’t need to touch the other DDDAudit result tables — just clear out PS_PTUPGDDDOUTPUT for these DDDTYPE values. The process will rebuild everything automatically when rerun.

If you’re rebuilding the environment from Prod, you can also verify there’s no preexisting PTUVIEW project data:

DELETE FROM PSPROJECTITEM WHERE PROJECTNAME='PTUVIEW';
DELETE FROM PSPROJECTDEFN WHERE PROJECTNAME='PTUVIEW';

Then rerun the PeopleTools upgrade step “Checking for Invalid Views on Microsoft.”

That should ensure the PTUVIEW project is rebuilt cleanly with only valid view names.

– Velu

Hello User_CAK3Z,

I have moved your post to the PeopleTools and Lifecycle Management - PSFT (MOSC).

I'm going to see about moving this to the Tools team so they can review.