dreport versus rreport

[Ian Wood]

On Mon, Mar 25, 2013 at 11:21 AM, Kenneth Brody <kenbrody at spamcop.net>wrote:

> 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
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list


In short, the above is NOT the case with the very example I sent to fptech,
they still have the files, so that can be verified.

I'm done on this subject, I've resigned myself to the fact that I now have
go through all my menus and find out which of my 5,243 processing tables
have to be recompiled with an alternate processing table.

We're in the middle of writing a version control library for our filePro
processes, and will modify that to include which auto process is to be
compiled with every output process that is checked in/out and will issue a
system command to compile both on check-in.

One would have thought that if this was a requirement of rreport, that when
using rcabe, upon asking the question "Do you wish to create a Runtime
table?" that rcabe would prompt for the associated automatic process with a
default of auto, and compile that at the same time.

Like I said, I'm done with this subject, we will put the measures into
place ourselves.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20130325/0fecd3de/attachment.html