rreport vs. dreport

[Brian K. White]

On 3/22/2013 2:35 PM, Ian Wood wrote:
> Okay, more fun discovered after our upgrade.
>
> We are trying to become SSAE16 compliant for one of our customers, a $2
> million revenue per year customer, and part of the audit procedure for this
> is that, for filePro, we have a development environment, a testing
> environment and a production environment with the production environment
> only having compiled executables on it, no program writing is to be done
> there.
>
> I modified all out menus to use rclerk and rreport instead of dclerk and
> dreport expecting all to be fine.
>
> (All .prc and .tok files are in sync)
>
> 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.
>
> I thought this was related to our recent upgrade to 5.07.03, but I have
> duplicated the issue in 5.0.14
>
> I've sent the necessary files to fpsupport at fptech.com (and fpsales, seeing
> as Bill Randall is the only one that gets back to us), just venting a
> little here and wondering if anyone else has experienced similar issues.

Yes all (at least 8 at the moment, I've actually lost count!) filepro 
programmers at Aljex have run into this and other mystery glitches where 
the fix was always to switch from rclerk/rreport to dclerk/dreport.

Years ago when I was newer I was on a mini pogrom of my own to swap out 
full paths to the d-progs with pathless r-progs in menus and system 
commands whenever I came across them in everything I touched. After a 
year or so I had a large portion of things replaced.

The older wiser heads said they had seen mystery problems in the past 
where the only thing they could figure out was it worked in 
dclerk/dreport. I being the supreme knowitall that I am, didn't trust 
their diagnostic thoroughness and didn't believe that could really have 
been the problem since in my vast experience to that date I had not yet 
run into such a situation, and I HAD seen them solve problems in inexact 
shotgun ways often.

Then we started having problems once in a while where nothing looked 
wrong and indeed it worked fine in dclerk/dreport. I saw it for myself 
in a few different cases and I do trust my own acuity and my own 
determination to slow down and look carefully and systematically, at 
least in some of the cases where the code wasn't too spaghettied. 
Actually, regardless whether the code was easy to follow or not, it's 
easy enough to verify that the binaries are the same version, the data 
is the same, all conditions the same except dclerk vs rclerk, and see 
the different result, and verify that that result can not be caused by 
any of the few intentional behavioral differences between d* & r*, like 
the debug command.

As far as I'm concerned it's a known thing. I don't have a data set. I 
don't have time to help fp figure it out. We've been burned by trying to 
help fp to fix other mystery bugs and after investing both time and 
money we never got a fix. We're also not willing to upgrade to anything 
that includes the license manager. We tried that too for a while and got 
burned on that too. So we just live with and work around the problems. 
If you saw the process we have to run every single minute from cron that 
scans through every single filepro file looking for file (record) locks 
and identifying certain types of locks on index headers and freechain 
anchors... this loop does so much work looking at hundreds of filepro 
files each with dozens of indexes and all multiplied by dozens of 
qualifiers... and it has to do all this every minute over and over just 
so that it can catch these mystery "lock-up-all-of-filepro" and clear it 
as soon as possible. It kills me every time I see this cron job. So 
stupid. By now I've managed to shift almost every other product we use 
to some open source equivalent, and gee guess what, we never have to 
just live with any such gross mystery problems in anything else but 
filepro now. Everything else can be debugged, and usually doesn't have 
to be anyways because fourteen thousand other people already found and 
fixed anything we run into.

No you're not alone.

-- 
bkw