[SOLVED] EXPORT ASCII won't - after action report

[Nancy Palmquist]

Jay,

That lazy copy of rreport over dreport or rclerk over dclerk is one of 
the things that drives me crazy on boxes.  They leave all the .prc 
tables but disable the development unless you have a magic wand.  What 
if the customer does an upgrade, that will mess up everything for the users.

I always wonder if the developer had the customer pay for a development 
version of filepro but then only let them access the Quickstart 
version.  How hard is it to put rclerk on a menu instead of dclerk?

I see mixed up versions like this all the time.  It makes it very hard 
to work on when you did not know what was done before you hit the system.

But as I work with code developed by others, I always have two 
reactions.  First, I learn how other people think and often solutions I 
would have never applied to the problem.  This is the good side.  
Second, I learn about all the ways programmers try to make filePro act 
like something it is not.  This is always the bad side.

Example, I work on one app that the developer wrote with Batch DOS 
Scripts.  So instead of looking at the menu to see what happens, you 
have to hunt up a Script and then see what will happen.  It even goes to 
a filepro file and does IF THEN logic to decide which DOS script to run 
in some cases.  I find this approach very difficult to document and 
follow.  But it works.  I can see the beauty of a script to send an 
email or translate a PCL to a PDF where you can use it from anywhere, 
but filepro can run scripts right on the menus and it makes it easier to 
follow.  One less step of tracing.

But I do learn quite a bit when I have to figure out how another 
programmer solved a data problem with filepro.  Viva la difference!

Nancy




On 6/8/2014 12:06 PM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Fairlight" <fairlite at fairlite.com>
>> My initial inclination was to exclaim, "You bastard!"
>>
>> Then I thought about working on the system in question, and I have now
>> modified it to, "You poor bastard!"
>>
>> :)
>>
>> (Does it have 'truss', so you could pull strace-style debugging?
>>   That'd be my next step.)
> Happily, I didn't (have to) go down that rabbit hole (and "no, of course
> it doesn't; it's SCO".)
>
> Ken's "add a show statement" tip was enough to make clear to me that it
> *wasn't running any of the code at all*, and that led me to "what's it
> running it *with*?".
>
> And it was then that I noticed "Define Runtime Processing" at the bottom
> of the left copy of the main menu.  Since this was a Menu Maestro install,
> it hadn't occurred to me at all that there might *be* tok tables... and
> then came the best part of all:
>
> Someone had copied rreport *over* dreport -- both had the same size and
> mod date.  So even my manual runs of dreport weren't going to find
> the prc tables.  I compiled it, and voila! (yes, that's how you spell
> that*) it worked perfectly.
>
> At that point I could start actually working on the, y'know, *work*, which
> (as expected) only took me half an hour.
>
> I will be generous (since this was a referral from the list) and assume
> that whomever decided that was a good thing to do had a good reason for
> doing it.  :-)
>
> My thanks to the various people who popped up with ideas both on- and
> off-list.
>
> Add this to your WTF? checklist.
>
> Cheers,
> -- jra

-- 
Nancy Palmquist
Owner
Virtual Software Systems - www.vss3.com
(412) 835-9417