Re Dreport/rreport - rant

[GCC Consulting]

I have been working on a new output for the last few days and suing dreport
to debug the program.

I had to put in a show statement to get me to the particular record where
the program would crash.  After working through a number of these caused by
either data errors or programming errors, I got the program working except
that after checking the last item which caused a problem, the program would
hang up.

I then tried running the output with rclerk and found that it ran much
faster.  However after running a few thousand records, the program hung
again.  As I knew which group of records to look at, I went to the file and
found the particular record that was causing the problem.  I discovered this
by trying to update the record in IUA and getting the record locked by
another process message.  I was them able to see what was causing the
problem and then program for it.  

I was wondering why filePro was never programmed to show the record number
of the record where the program ran into trouble and an error message was
displayed.  It sure would make it a lot easier to debug a program if one
could turn on the debugger when that record was being processed so you could
possibly see where the problem was before the error message was displayed
again.

Well, it seem like my program will finish processing all 142,000 records
shortly and I can then check the results.  This is an output creating a CSV
file.  Opens in Excel but not Open Office.  Open office complains that there
are too many rows.


Richard Kreiss
GCC Consulting

Office: 410-653-2813