I've been tying to validate data in a field on a multi-line form, but to no avail. Validating one field is simple. My problem comes from trying to validate, say a qty field tctkn090.dqua, such that the sum(tctkn090.dqua) <= a total value zoom.tqua that was imported into the session. The maintain session has 11 lines (therefore 11 dqua fields) per form. Since this field does not have a fixed field name like dqua.1, dqua.2, dqua.3 etc but is rather individual records in table tctkn090, I'm having problems getting the sum of this field tctkn090.dqua while in the maintain session. The real problem is trying to get the code to work for various scenarios. I can insert records and then do a running sum using a variable (since the record is not committed to the table as yet), but would not work, if along the way of adding records I deleted a range of lines. Also assume that we have some entries previously and we added a new set of records, then we have a combination of records that exists in the table and newly entered records stored in some buffer somewhere???
Has anyone done this before?

Running totals take a lot of coding, as you saw you have to account for adds, deletes and updates that are buffered and not yet committed. You can get there, but is that what you really want?

Consider that you may have more than 1 screen that must add up to the total, right? So, you will have to commit sometimes (to scroll in entries on the screen) before you can check if you balance. So, is it really reasonable to expect things to balance for every save?

Usually these type of checks are done before allowing the user to exit the session (end.program (and abort.program) / before.choice / use choice.again() to prevent). Call the save first, then run SQL to see if it balances, don't let them leave until they do (or give them an option that removes the records and starts over). This is the method used, for example, to check that a Journal Voucher batch total matches the control total entered, you cannot exit the session until you balance.

On the running totals, the easist way is to allow the save and to then post up the current total using SQL.

To get the running total of what is entered before the save, this is the most difficult. You need to save the old values of the field (in the before input section), then in the after input section you can update your totals by subtracting the old value and adding the new. (works best if the default value for new records is 0).

For deletes, in the before delete section, you can see what records are going to be deleted using the mark.handler command (check the programmers manual) and removing the values of those fields. Use the 'do.occ' function to make sure you remove the right values.