dreport versus rreport

[Kenneth Brody]

In answer to the recent "rreport vs. dreport" thread, along with the "I've 
been using filePro for ${BIGNUM} years, and I've never run into this before" 
comments...

I hope this clears things up.

======

Short answer:

If you want a "blanket rule", it would be "you *should* compile the output 
processing with the same '-y' table as you will run it with -- however, in 
nearly all cases, the difference in compilation will have no effect on 
filePro during runtime".

But, in those few cases where it *does* have an effect, that effect will 
cause the report to fail to run properly if not compiled properly

======

Long answer:

The difference has to do with the "multi-level copies" of dummy fields, 
which allows you to use a single dummy field to hold multiple subtotal 
values.  (See my article in Smalltalk #9.3 pp7-11, "Output Processing: 
Subtotals, Dummy Fields, Aliases and Arrays" for more details if you are 
unfamiliar with this feature.)

Specifically, it has to do with whether the dummy field you are using to do 
such subtotalling is defined in automatic processing, but not in the "-y" 
override.  And, whether you use that field to accumulate a value without 
having executed an explicit assignment to that field.

For example:

     aa = aa + ytd_sales

without executing something like:

     aa = ""
or
     aa = some_value

IF you are using a dummy field for multi-level subtotalling,

AND IF you accumulate a value into that dummy field without an explicit 
assignment,

AND IF you are running rreport with a "-y" table that does not define that 
dummy field,

AND IF your default "automatic" processing table does define that dummy field,

AND IF you compile the output table without the corresponding "-y" (or you 
do use a "-y", but that table also does not define that dummy field),

THEN, the output may not run correctly.

======

But, as I said above, the rule of thumb is that you "should" compile it with 
the corresponding "-y", even though probably >99% of the time it's not going 
to make a difference (as noted by the "I've never run into this in all my 
years of programming filePro" comments), because that one time it does 
matter, it matters big.

-- 
Kenneth Brody