Heading data and page breaks.

[DonQuixote]

In a GRIM report I do page break on a Vendor number.  In the heading of the report is the Vendor number.  If there are exact the right number of lines to fill the page and the Vendor break is happening at the same time; the heading is showing the next vendor but printing the totals for the prior vendor.

What can I do to print the vendor number associated with the break instead of the next line?

[Tom Pellitieri]

This is an SB+ "glitch" that has been around for a long time. 

The header section uses data from the current record.  A record with a new value is read before the break section, and the corresponding new page can be generated, so when a break section prints, the "current" record is the first data record of the next break section. 

You could try to save the information you need in the Process After Read slot, but you need to keep two items:  the current record and the prior record.  You could use @PARMS(38) and @PARMS(39).  After each read, assign @PARMS(38) = @PARMS(39) and @PARMS(39) = @RECORD.  @PARMS(38) would then be the last record included in the break section.  Of course, you need to preload @PARMS(38) before the first read somehome.  I suspect you could set it to null at the start, then if it is null, set it to @RECORD, otherwise @PARMS(39).

--Tom

[DonQuixote]

this sounds good.
But, in my case I need both the prior RECORD and the prior ID.
Following your logic would I also save prior ID in PARMS(36) and current ID in PARMS(37)?
@PARMS(36) = @PARMS(37)
@PARMS(37) = @ID

[Tom Pellitieri]

Since you need the prior ID, you can just save it instead, and then use F("File",OldID)<Field> as the source of the header data, rather than keeping the whole record.  In that case, you could use two @WORK items (e.g., @WORK<1> and @WORK<2>), since you don't need to save a multi-attribute item.

--Tom

[precisonline]

Hey Tom, didn't we already solve this somewhere else in here?

You're right, this is a longstanding bug in SB+.  However, adding a process after read isn't likely to solve the issue because the process after read happens before the break processing is done.  I usually drop a field on the print line that shuttles the heading values into @USERDATA(..) somewhere, and then a Proc At Start that clears the @USERDATA(..) values.  Then, in the heading you can do a derived value something like this:

IF(@USERDATA(5)<1> # '',@USERDATA(5)<1>,originalFieldName)

The process called on the print line would then do something like this:

@USERDATA(5)<1> = originalFieldName

Haven't done this in a while, hope it still works!