State Records and Missing Data May 22, 2007
Posted by Duncan in Application Engine, PeopleSoft, SQL.trackback
We’ve encountered an issue today that we hadn’t noticed before. Within an Application Engine program we populate a state record (AET table) with values. The first time we use these values (i.e. retrieve them using %Bind(<fieldname>)) the values are retrieved successfully, however when we attempt to use the values a second time they are empty/blank.
This occurred because our State Record was set as a Derived/Work record and our App Engine did not have restart disabled. As a result it was performing Commits after each Section (the default behaviour), and – this is the gotcha – a commit clears down the State Record!
According to PeopleBooks, this is by design. If you wish to have commits in your App Engine then your State Record must be setup as a SQL Table to keep its values.
This implies that you may need 2 state records for larger/more complex AEs. One SQL Table AET to hold variables that you wish to reference throughout your program, and one Dervied AET to hold values that you’ll reference immediately (i.e. variables that you wish to use in Dynamic SQL, like within a DoSelect).
There is a Customer Connection case explaining it further:
http://www.peoplesoft.com/psp/portprd/CUSTOMER/CRM/c/C1C_MENU.C1_SOLN_SUMMARY.GBL?page=C1_SOLN_SUMMARY&SETID=SHARE&SOLUTION_ID=201024788
Comments
Sorry comments are closed for this entry
The PeopleSoft Tipster Blog 
I build all my AET’s as SQL tables. I don’t believe there is any downside to this approach. My AppEngine instructor recommended avoiding derived/work state records. What are you hoping to gain by setting your table type to derived/work?
I certainly develop most of my AEs with the State Record as a SQL Table, partly as it aids with debugging. It’s a surprise how many people disagree with this approach though. I concede that having the AETs as a Dynamic/Work records avoids the overhead of the data being saved to the DB at each commit, but honestly can’t see that saving a single row of data (after all that’s all an AET will contain) presents a significant overhead.