rreport vs. dreport

[Bruce Easton]

On 3/22/13 4:02 PM, Brian K. White wrote:
> On 3/22/2013 3:37 PM, Ian Wood wrote:
>> On Fri, Mar 22, 2013 at 2:53 PM, Kenneth Brody <kenbrody at spamcop.net> wrote:
>>
>>> On 3/22/2013 2:35 PM, Ian Wood wrote:
>>>
>>>> Okay, more fun discovered after our upgrade.
>>>>
>>> [...]
>>>
>>>    We have a report that runs from a filePro file and writes out to a .csv
>>>> that then gets pulled into an Excel spreadsheet.
>>>>
>>>> Silly me expected the same report running in dreport to have the same
>>>> results in rreport
>>>>
>>>> The report runs as expected in dreport, but is missing information when
>>>> run
>>>> from rreport.
>>>>
>>> [...]
>>>
>>> Quick question:
>>>
>>> Do you run rreport with "-y" to override automatic processing, but did not
>>> compile the output processing with the same "-y"?
>>>
>>> --
>>> Kenneth Brody
>>>
>>
>> I have been around filePro since 1.0 days and have never had this issue
>> arise. SMH. That worked for this instance.
>>
>> Now I have to go through all my menus and all my batch files, again, and
>> find all instances of rreport that have a -y associated and recompile.
> I didn't know about this the last time I looked into d*/r*
> discrepancies, so who knows this might have resolved our problems too.
>
>> Another question. What if I have the same output process that uses the
>> regular auto process, yet elsewhere uses an alternate auto process?
> ..or no auto. Good question. May just be a fundamental limit in the way
> fp works that some things are determined at compile time.
>
It has been quite a while since I've seen any problem like this, but 
there was a period of time where, under Unix filepro, we could only run 
dreport for a couple of key processes.  This was rare - and we had two, 
maybe three places where we had readme files to alert the developer to 
not attempt to change d to r for the menu options.  I certainly do not 
remember any documented reason for the problem.  I also do not remember 
which version number this problem popped up under, but most likely 
3.something to 4.something.  I do remember that I did at the time know 
about the importance of tokenizing against the automatic table that 
would be called to ensure the proper sharing of dummy field edits, 
globalization, etc.  This would have been one of the top couple of 
things on our list to check at the time, and I believe notes stating 
that this had been checked were included in these old few readme files.  
I don't believe we have any of the programs where these few issues 
cropped up in use anymore, but I certainly remember beating my head 
against the wall for a day or so over it. :)

Regarding "Another question" - same output process and different auto 
table - I don't  understand how that would be useful.

Bruce Easton