The Peoplesoft-pagebar can contain the following hyperlinks:

According to customer’s standards, each page should show (only) the ‘Help’ hyperlink, which can be configured via the component properties (yellow marked) as shown in the screenshot below.

 How to establish what components do not meet this standard?

It turned out that all yellow marked properties together make up the (bitmap) value of Peoplesoft systemtable-field PSPNLGRPDEFN.SHOWTBAR (eg. 63 in case of screenshot above). For your convenience,  i added an Excel-sheet which will calculate the value for this systemtable-field based on your input.

Now it’s easy to establish what components do not meet the standard, i used the following script:

SELECT *
FROM PSPNLGRPDEFN pg
WHERE showtbar NOT IN (56,
                       57)
  AND EXISTS
    ( SELECT 'y'
     FROM PSAUTHITEM a
     WHERE a.baritemname = pg.pnlgrpname
       AND EXISTS
         ( SELECT 'y'
          FROM PSROLECLASS rc
          WHERE rc.classid = a.classid
            AND EXISTS
              (SELECT 'y'
               FROM PSROLEUSER ru
               WHERE ru.rolename = rc.rolename)))
ORDER BY pg.pnlgrpname

Next step could be creating an update-script to set PSPNLGRPDEFN.SHOWTBAR (for selected components) to a desired value.

I hope you can use this to your advantage.

(PeopleTools release 8.47.08, Oracle 9i Enterprise Edition Release 9.2.0.6.0 – 64bit Production)

As a Peoplesoft developer (working with Peopletools-release 8.47.08), I have spent quite some time resolving issues caused by unexpected database-commits. As far a I know there’s no overall topic on this in Peoplebooks, therefore I will share my experience via this blog.

1) Database-updates via DML in a SQLExec-statement (e.g. INSERT INTO PS_TEST_TABLE VALUES(‘value_field_1′,’value_field_2′), triggered via an online component:
Peoplebooks states that DML in a SQLExec-statement is only allowed in FieldChange, SavePreChange, Workflow and SavePostChange events.
There’s a big difference in the outcome per event though; when this statement is put in a FieldChange-event, the DML is committed instantly, and this is something you probably don’t want!

2) Database-updates via DML in a SQLExec-statement (e.g. INSERT INTO PS_TEST_TABLE VALUES(‘value_field_1′,’value_field_2′), triggered via an Application Engine:
These updates are being committed according the AppEngine’s commit-settings.

2) Database-updates via a component interface, triggered via an online component (e.g. component A triggers component interface B_CI, triggering component B):
These updates are being committed as soon as the CI save-method is being invoked from the calling component (e.g. component A).

3) Database-updates via a component interface, triggered via an Application Engine (eg. AppEngine AE_1 triggers component interface B_CI, triggering component B):
These updates are being committed according the AppEngine’s commit-settings.
An exception to this rule I just recently encountered: the GetFile-statement leads to an immediate commit, even when used in an AppEngine-context!