Prompt Edit on Create Keys does not work on Component Interfaces

In a Component Interface while calling the create method, when an invalid value is entered in a record field(create key) having Prompt Table with Edit, the data gets saved. In other words, Save() method executes successfully though there is an invalid value entered in the create key with a Prompt Table Edit.

This happens because while assigning value to the create key, the CI is still uninstantiated and the prompt table edit does not get executed then. The invalid value is accepted by the system as the validation does not happen against the prompt table.

As a solution to this issue, we can access the search record\Add search record of the component and select "SearchEdit" in the record field properties of the Create Key field. This will ensure the validation is triggered on the Create key.

PeopleCode Metatables

Peoplecode Audit:
At times, we have the necessity to find audit details of a particular peoplecode on a particular object. When we check the LASTUPDDTTM of a record or a page or a component, it does not give us the required information since the definition itself hasn't got changed by writing peoplecode. However, there is an answer to this. Most of the PeopleSoft technical consultants know that PSPCMPROG table stores the peoplecode. PROGTXT field in PSPCMPROG record stores the peoplecode however it cannot be retrieved in a readable format since the code is saved in binary format in the database.
PSPCMPROG record provides us two fields - LASTUPDDTTM and LASTUPDOPRID which gives us information on when the peoplecode was last modified and by whom.

References to objects in peoplecode:
I found something more interesting while verifying this sometime back. PSPCMNAME table contains two fields RECNAME and REFNAME which caught my attention. For every reference to a PeopleTools object referenced from peoplecode, an entry is written into this table. For example, if a Record.Field.Fieldchange event references five different PeopleSoft objects then there will be five entries in this table. I believe this is how PeopleSoft's cross reference utility\Definition references works. Surely give this a shot, when you have to do a definition reference next time.

How to read a SQL Trace in PeopleSoft

As always with so many things, I struggled initially to understand the trace file. More often, I would generate a trace file and did not understand every aspect of the trace file. However with experience, I have figured what is written to the trace file and sharing my findings below.

When a trace is run for SQL statements, the resulting trace statement will have various parts. Here is the list along with the description.

First Part: n-xxxxx.
This is a sequential line counter for the process (exe). n is a integer starting from 1 to n. xxxxx is reserved for each line written to the trace file. If there is a second process, then it would be 2-xxxxx, for the third one it would be 3-xxxxx and so on.

Second Part:
It indicates the timestamp at which the trace line is written. This timestamp is retrieved from the machine in which PeopleTools is running.

Third Part: A time value
This is the time elapsed since the previous trace line was written. The time elapsed between n-xxxxx and n-(xxxxx+1) is written.

Fourth Part: Cur#n
This indicates the cursor number for the statement

Fifth Part: PSFT_DB
Indicates the PeopleSoft database in which this API call is executing.

Sixth Part: RC=0
This is the return code for the associated API call.

Seventh Part: Dur=Another time value.
This is the time to execute the assoicated API call.

Eight Part: COM Stmt=<SQL Statement>
This is the database API call and provides information on the SQL executed.

Next post is on reading a Peoplecode trace.