2

I'm trying to get a better understanding of what Rows and Rowsets are used for in PeopleCode? I've read through PeopleBooks and still don't feel like I have a good understanding. I'm looking to get more understanding of these as it pertains to Application Engine programs. Perhaps walking through an example may help. Here are some specific questions I have:

  1. I understand that Rowsets, Row, Record, and Field are used to access component buffer data, but is this still the case for stand alone Application Engine programs run via Process Scheduler?

  2. What would be the need or advantage to using these as opposed to using SQL objects/functions (CreateSQL, SQLExec, etc...)? I often see in AE programs where the CreateRowset object is instantiated and uses a .Fill method with a SQL WHERE Clause and I don't quite understand why a SQL was not used instead.

  3. I've seen in PeopleBooks that a Row object in a component scroll is a row, how does a component scroll relate to the row? I've seen references to rows having different scroll levels, is this just a way of grouping and nesting related data?

  4. After you have instantiated the CreateRowset object, what are typical uses of it in the program afterwards? How would you perform logic (If, Then, Else, etc..) on data retrieved by the rowset, or use it to update data?

I appreciate any insight you can share.

Nick
  • 268
  • 8
  • 33

1 Answers1

6
  1. You can still use Rowsets, Rows, Records and fields in stand alone Application Engines. Application Engines do not have component buffer data as they are not running within the context of a component. Therefore to use these items you need to populate them using built-in methods like .fill() on a rowset, or .selectByKey() on a record.

  2. The advantage of using rowsets over SQL is that it makes the CRUD easier. There are built-in methods for selecting, updating, inserting and deleting. Additionally you don't have to worry about making a large number of variables if there were multiple fields like you would with a SQL object. Another advantage is when you do the fill, the data is read into memory, where if you looped through the SQL, the SQL cursor would be open longer. The rowset, row, record and field objects also have a lot of other useful methods such as allowing you to executeEdits (validation) or copy from one rowset\row\record to another.

  3. This question is a bit less clear to me but I'll try and explain. If you have a Page, it would have a level 0 row. It then could have multiple Level 1 rowsets. Under each of those it could have a level 2 rowsets.

                Level0
               /      \
         Level1       Level1
         /      \      /     \
     Level2   Level2 Level2  Level2
    

If one of your level1 rows had 3 rows, then you would find 3 rows in the Rowset associated with that level1. Not sure I explained this to answer what you need, please clarify if I can provide more info

  1. Typically after I create a rowset, I would loop through it. Access the record on each row, do some processing with it. In the example below, I look through all locked accounts and prefix their description with LOCKED and then updated the database.

.

Local boolean &updateResult;
local integer &i;   
local record &lockedAccount;
Local rowset &lockedAccounts;

&lockedAccounts = CreateRowset(RECORD.PSOPRDEFN);
&lockedAccounts.fill("WHERE acctlock = 1");

for &i = 1 to &lockedAccounts.ActiveRowCount
    &lockedAccount = &lockedAccounts(&i).PSOPRDEFN;
   if left(&lockedAccount.OPRDEFNDESCR.value,6) <> "LOCKED" then
      &lockedAccount.OPRDEFNDESCR.value = "LOCKED " | &lockedAccount.OPRDEFNDESCR.value;
      &updateResult = &lockedAccount.update();
      if not &updateResult then
           /* Error handle failed update */
      end-if;
   end-if;
End-for;
Darryls99
  • 921
  • 6
  • 11
  • `if left(&lockedAccount.OPRDEFNDESCR.value,6) = "LOCKED" then &lockedAccount.OPRDEFNDESCR.value = "LOCKED " | &lockedAccount.OPRDEFNDESCR.value;` I hope your OPRDEFNDESCR isn't a LOB, because I don't think you understand what you are doing here. – Based Oct 29 '18 at 08:52
  • Thank you for the explanation! So the ActiveRowCount property is the termination point of the loop? Is this the best way to process logic using the Rowset (looping through)? The CreateRowset is essentially firing a command to the database that would translate to `SELECT * FROM PSOPRDEFN WHERE acctlock = 1` ? So all of the row values are stored in memory into the variable &lockedAccounts after the .fill property is executed? And then below that is where processing is occuring? – Nick Oct 29 '18 at 12:02
  • @Nick Yes to all your questions. My only slight change is that the sql statement is actually sent as `SELECT * FROM PSOPRDEFN FILL WHERE acctlock = 1` which is useful to know that the table is aliased as FILL if you want to write a subquery that relates back to the main record. – Darryls99 Oct 29 '18 at 15:58
  • Thank you for the feedback! – Nick Oct 31 '18 at 11:31
  • @Darryls99 Just circling back on this if I may, in your answer above, under response 4, you stated that the rowset will "Access the record on each row". When you say record, are you referring to the physical database table, or the actual row as being the "record"? I just wasn't sure of the context, as I would interpret what you said to mean "access each row on the record" but maybe your referring to record as something other than a SQL table? Thanks for the clarification! – Nick Feb 20 '19 at 14:21
  • @Nick A PeopleSoft record in a SQL database context is a single row from a single table. Each PeopleSoft Row contains 1 or more records. example: `SELECT RD.ROLENAME, RD.DESCR, RU.ROLEUSER FROM PSROLEDEFN RD JOIN PSROLEUSER RU ON RU.ROLENAME = RD.ROLENAME WHERE RD.ROLENAME = 'PAdmin'` results in 'PAdmin, PAdminPriv, darryls99' 'PAdmin, PAdminPriv, nick' or in psuedo PeopleCode: `row(2).PSROLEUSER.ROLEUSER.value would be nick row(2).PSROLEDEFN.ROLENAME.value would be PAdmin` so `Row(#).Record.Field.value` let me know if you need more – Darryls99 Feb 21 '19 at 20:18
  • @Darryls99 so in your example above, your setting the record variable `&lockedAccount` equal to the entire row in PSOPRDEFN (&lockedAccounts(&i).PSOPRDEFN; ) ? Or are you getting individual values? Maybe it would help if I could see what the output values would be from that expression. Appreciate the guidance! – Nick Feb 22 '19 at 18:47