Within the new PeopleTools versions PeopleSoft often uses Component Interfaces in PeopleCode to adjust data. These constructions are sometimes very hard to understand. Especially if the update of data goes wrong, the error generated from the Component Interface is tucked away in an array which can only be read when debugging the proces.

There is a very simple way to get around this.

Since PeopleSoft is an Internet architecture one suspects that it should support the commonly used RSS feeds that are available through internet. And guess what: it does!

Let me show you by adding the RSS feed of my favorite soccer club (http://rssfeeds.headliner.nl/rssfeeds/az/feed.xml).

Go to PeopleTools > Portal > Pagelet Wizard and add a new value. In the first step, specify a title and a meaningful description (might be the hardest part):

Imagine this; you open your recently saved project in PeopleSoft Application Designer and…all of your precious code has vanished!
Your first thought might be “Well at last something exciting is finally happening on my (in general boring) office jobs!”. And your second thought should be “What the **** happened to my precious peoplecode!?”.

Sometimes you want to create a view in PeopleSoft which is based on another view.

Example:
View 1 (named PS_LOCKED_USR_VW) is defined as follows:
SELECT OPRID FROM PSOPRDEFN WHERE ACCTLOCK = 1;

View 2 (named PS_GET_LOCKED_NAME_VW) is defined as follows:
SELECT A.NAME FROM PS_PERSON_NAME A, PS_LOCKED_USR_VW B WHERE A.EMPLID = B.EMPLID;

When creating views using the createvw.dms script (or the REPLACE_VIEW * command from Data Mover) the situation above creates an error, because Data Mover is building views in alphabetic order. This means that views PS_GET_LOCKED_NAME_VW is built before view PS_LOCKED_USR_VW and goes into error.

Running the DDDAUDIT.SQR process is something every PeopleSoft administrator should do on a regular basis, because it detects flaws between objects in the database and the corresponding definitions in the PeopleSoft data dictionary.

In normal maintenance life however this process doesn’t run that often, so the output can be quite large. Also, when running a DDDAudit during upgrades, there can be a lot of records (TABLE-3 check) and views (VIEWS-2 check) that are obsolete in the new version thus have to be removed. These objects have to be removed manually, which can be a lot of work.

By adjusting the DDDAudit script a bit this work can be reduced a lot. The trick is to write a drop statement to a new file after the record or view that has to be deleted is printed to the output report.

I’ll illustrate it by adding the necessary code to the TABLE-3 check for a Microsoft SQL Server database. In the dddtable.sqc file (which is called from the dddaudit.sqr) add the following lines: