Author Topic: Data Fields In SB+ ReportWriter Headings  (Read 5181 times)


  • President
  • Administrator
  • Rock Star
  • *****
  • Posts: 1612
    • Precision Solutions
Data Fields In SB+ ReportWriter Headings
« on: January 04, 2008, 02:34:55 PM »
Every now and again there are those situations that arise with SB+ where the need is so rational but the implementation provides untold challenges.  Such is the situation with putting data fields in ReportWriter headings.

You've probably faced this one yourself a time or two, where the report is sorting and breaking on a field with a subsequent page break.  Maybe the detail line is a bit cramped so we want to move something - maybe a salesman number - up to the heading so that it shows up once per page instead of repeated down a column.  This is a very rational situation wouldn't you agree?

It's no big deal to put the salesman number field in the heading, and it will show up properly MOST of the time.  If the break section itself happens to flow over to the top of the next page, the heading will be printed with the next salesman instead of the salesman whose totals are being show.  This is a vexing problem for users, who get more than a little irritated seeing Gerald's name at the top and Frank's totals below.

Having faced this problem more times than I care to admit, and having come up with some bona fide screwy solutions, I've decided that these methods were just too much work and too inflexible.  Thanks to the customer who asked me this question today, I think we've finally found a workable answer that ISN'T too much work and may very well make this a non-issue for the future!

Here's the basics of the problem.  In order for the SB+ ReportWriter to know a break is to occur, it has to read the next record containing a different value in the break field.  When that happens, the break section is output.  So far, no big deal.  However, it's more than likely we have that same field (used for break) being shown in the heading.  When the break rolls over to the next page, the heading shows what's in the current record (i.e. the next record) and thus shows the next salesman in the heading with the totals for the previous person.

If only we knew that the heading was being output during the detail section, or the break section, or even the grand total section.  That way we could adapt our heading value accordingly.  Well, as luck (and good design) would have it, we actually do have that information in a variable called @RV.SECTION.

@RV.SECTION, according to the documentation, has three values.  If the heading gets triggered during the processing of the detail section, this variable holds a "D".  If the heading gets triggered during the processing of the break section, this variable holds a "B".  And finally, if the heading gets triggered during the processing of the grand total section, this variable holds a "G".

At the beginning of the report, before the first detail line is printed, this will be a "D", telling us that the heading was triggered by the first detail.  At this point, we could show a value from the record.  Any time this came up as a "B", we'd know that the break overflowed the page and so we'd want to show the previous value from @ORIG.REC.  And then in the grand total section, we might not want any value to show.  This could be written using a derived value expression something like this (assuming SLSM.NUM is the break field):


That's a pretty hefty derived value, which makes it something of a pain to reuse, so we might rewrite this as a standard paragraph, maybe something like this:

  @VALUE = ''

This process - we'll call it GET.HDG.FIELD - could then be called in the derived value slot of a heading field like this:


...which could then be reused for any heading field on any report!*

*Not really.  There are variations on this theme based on whether the break field is in the record, an extracted piece of a field in the record, a calculated value, or whether the break field is the key or part of it.  That being said, this solution is only applicable for those data fields with a positive numbered field position - that is, real and complete fields in the record.  If the break field is a derived value or the key, well, that'll require something a little different...

Hope this helps!
Accidents "happen"; success, however, is planned and executed.