Author Topic: Another Weird ReportWriter Issue  (Read 4427 times)

precisonline

  • President
  • Administrator
  • Rock Star
  • *****
  • Posts: 1612
    • Precision Solutions
Another Weird ReportWriter Issue
« on: June 10, 2008, 09:49:58 AM »
You may know that the SB+ ReportWriter sets @KEY = @AM as an indicator that the list of selected records has been exhausted.  In most BASIC programs we'd use a sentinel, but SB+ uses UNTIL @KEY = AM DO ... in the ReportWriter to know when the list is done.  But did you know that this feature can cause some problems?

I didn't either until today.

I just finished debugging a report that was losing it's mind somewhere around the final break of the report.  This report started with a paragraph that had stuffed a bunch of values in @WORK before calling the PD.R, and then at the end of the report it was expecting those values to be where the paragraph had originally placed them.  But they weren't; they were shifted from W26 to a lower attribute.

The problem was in an inline paragraph (uggh) in the Process Before Break which said this:

Code: [Select]
P:(IF @OTHER(8)<14> = 1 THEN @WORK<6> = CO.NUM : CUR.WHSE)
My general distaste for inlines aside, this basically looks like it should work.  The @WORK<6> variable is a data element in the heading, and this code is intended to make sure the heading matches the data if the heading flows over to the next page.  (Fortunately, we have a better way to do this as explained at http://www.precisonline.com/forum/index.php/topic,86.0.html .)

But on the final break, this was completely torching @WORK.  Everything following @WORK<6> was shifting down one attribute on the final break.  Weird, huh?

CUR.WHSE is defined as attribute 27 of @RECORD.   CO.NUM is a derived field that reads: (<0>"G0!1")  And other than this inline, there are no other processes contributing to this error.

So here's what happened: <0>, being the key, was an attribute mark on the final break (because the select list had been exhausted).  CUR.WHSE was null.  Therefore, the expression <0>"G0!1" returned that attribute mark, so this inline was basically setting @WORK<6> = @AM, which inserts the attribute mark into @WORK at that location and pushes everything after attribute 6 down one position.

The manifestation in this particular case was the report would not output to the right location.  You could set it up to go to email or fax, but it'd never go there because the wrapup code that does the emailing/faxing expects @WORK values to be where they were originally placed.  In this case, those values got shifted an attribute.

So if you're having difficulties with a report that should email or fax but isn't (using the Prelude standard processes), you might take a look at processes like this to see if @WORK might be getting shifted inadvertently.
« Last Edit: September 16, 2008, 10:25:27 AM by precisonline »
-Kevin
Accidents "happen"; success, however, is planned and executed.