I want to post this out here so others experiencing it have someplace to compare notes. I have a pre-fab data table to support a particular report on my system. So the report is very simple --

 
TABLE FILE ACIS_FR_13
SUM
     ACIS_FR_13.ACIS_FR_13.NBS
     ACIS_FR_13.ACIS_FR_13.REI
     ACIS_FR_13.ACIS_FR_13.RWL
     ACIS_FR_13.ACIS_FR_13.XLC
     ACIS_FR_13.ACIS_FR_13.NPP
     ACIS_FR_13.ACIS_FR_13.COC
     ACIS_FR_13.ACIS_FR_13.CRQ
     ACIS_FR_13.ACIS_FR_13.FRD
     ACIS_FR_13.ACIS_FR_13.NPS
     ACIS_FR_13.ACIS_FR_13.VOC
     ACIS_FR_13.ACIS_FR_13.DIS
     ACIS_FR_13.ACIS_FR_13.SLD
     ACIS_FR_13.ACIS_FR_13.XFR
     ACIS_FR_13.ACIS_FR_13.ACT
     ACIS_FR_13.ACIS_FR_13.CAN
     ACIS_FR_13.ACIS_FR_13.BDT
     ACIS_FR_13.ACIS_FR_13.OTH
     COMPUTE OTH_PER/D6.2% = ACIS_FR_13.ACIS_FR_13.OTH * 100 / ACIS_FR_13.ACIS_FR_13.XLC;
WHERE RECORD_YEAR EQ '&YEAR'
WHERE RECORD_MONTH EQ '&MONTH'
WHERE MASTER_NAIC NOT LIKE '-%'
BY TOTAL HIGHEST COMPUTE OTH_PER/D6.2% = ACIS_FR_13.ACIS_FR_13.OTH * 100 / ACIS_FR_13.ACIS_FR_13.XLC; NOPRINT
BY HIGHEST TOTAL ACIS_FR_13.ACIS_FR_13.XLC NOPRINT
BY  ACIS_FR_13.ACIS_FR_13.MASTER_NAIC
ON TABLE HEADING
"FR13 for &MONTH/&YEAR"
ON TABLE SUMMARIZE
COMPUTE TOT_OTH_PER/D6.2% = ACIS_FR_13.ACIS_FR_13.OTH * 100 / ACIS_FR_13.ACIS_FR_13.XLC;
-*ON TABLE PCHOLD FORMAT HTML
ON TABLE PCHOLD FORMAT AHTML
-*ON TABLE PCHOLD FORMAT EXL2K
-*ON TABLE PCHOLD FORMAT EXL2K FORMULA
END

This is tried-and-true code, running in WF Version 7.7 for months in AHTML output format. With our move to WF Version 8 the report goes completely sideways in the pipe, printing an extra field at the beginning but with the same headings as the original (i.e., the numbers on the report are all shifted a column) and one of the numbers that appears in a single field in the first record is being duplicated all over the table in place of zeros, in spite of it not appearing multiple times in the underlying html source code. The source code in the html data does not match the contents in the displayed table. And the Summary row at the bottom of the report is fully correct, contradicting the information in the table above it. Really a strange error.

The report runs identical to Version 7.7 in Version 8 in the HTML, PDF, EXL2K and EXL2K FORMULA formats. This is just an AHTML issue.

The data that is loaded into the AHTML viewer in the IE page has more digits to the right of the decimal point in version 8, which is fine, doesn't matter to me. But the numbers being shown in the table on the screen are just wigged out. The focexec source code doesn't seem to support their printing, let alone the report's html source code. This is in IE 11.0.9600. I get the same error in Firefox 47 and Chrome 51.0.2704.

My jaundiced programming eye is drawn by that BY TOTAL HIGHEST COMPUTE line, which is way too complicated for its own good. But hey, it works in Version 7 and every output format in Version 8 that I use except for AHTML.

I have to get Version 8 out so I'm leaving this as it is. I will offer it in HTML and EXL2K formats only in order to solve the problem. But I figured I'd get the information onto the street for anyone else stumbling into the same issue. As often as not I search the forums for a problem and discover a programmer identifying it, and that's helpful. Often there's a solution, and to my chagrin I've looked to see who provided that answer and find my own ID to the left of the post! A message to myself in the future. Am I the only person that happens to?

This message has been edited. Last edited by: John_Edwards,

John --

1. Perhaps 8 is thrown off by the combination of
BY TOTAL HIGHEST
and
BY HIGHEST TOTAL

2. Does this behave nicely when the COMPUTE after the SUMMARIZE is omitted?

Good questions. I didn't write this one and I'm thinking it was done in the tool. We never put the segment prefixes on when we do them by hand.

It runs in all the other formats and frankly, if I was writing a compiler I'd have the results fully built first and then put it into whichever format was needed. So it wouldn't make a difference. But that's Monday morning quarterbacking. Something about this one in particular is hosing the output.

My client requested Excel format so this has become a low priority.