PeopleSoft Learning

Derived Work Records in Peoplesoft

"Derived records" are useful PeopleSoft objects, but sometimes there is some confusion about them.

PeopleSoft makes normal data entry pages a snap to create. But for more complex page designs, we must use elements that are not directly bound to tables or views. This is where derived records are useful. Now, we might think that a derived record field should act exactly the same as a "real" table column on a page. Sometimes this is true, but not always.

If you try to define a scroll area or grid consisting only of derived record fields, the page will not be valid. These objects must contain at least one "real" database field. Sometimes, though, it is necessary to create a scroll or grid that doesn't relate directly to a table or view. One easy way around this problem is to create a dummy view containing just one field that returns one blank space or other unused value. Put that field into your scroll or grid, mark the scroll/grid as "no auto select," and you can now fill and manipulate the scroll/grid without any complaints from the system. (I have also used a dummy view as a component's search record when I wanted to do all of my data selection in code.). Dynamic views can be used as dummy view with no Sql in its definition. This avoids us from creating any database object.

Another major difference between derived and other records is in the way the component processor handles keys to tables and views. When you have several tables or views on a page, and a search record attached to the component, you know that selecting one row on the search dialog causes all of the related data to be loaded automatically. The various records share their keys. The component processor looks at the definition of each record, finds the keys, and checks to see whether values are available for those keys (from other records on higher scroll levels). If so, those key values are used in loading the data. But derived records do not participate in this. You can set a derived field to a value before the page loads (in PreBuild, for example), but that won't help. You need to do actual SQL using SQLExec() or Select() or some other function/method.

I don't really know why these limitations exist. But they do, and understanding that they are there will help to eliminate many bugs and uncertainties about how our pages operate.

Posted by

Ganesh A.M