Incorrect RList total in v1.16? (AREV Specific)
At 24 OCT 2001 06:36:03PM Warren wrote:
Running a "LIST filename TOTAL field" in ARev 1.16 sporadically gives an incorrect total on one file.
Taking the amounts listed in the report and totalling them manually on an adding machine/calculator comes out to an amount different from what RList reports. Total seems to be off by the first value listed. The amount field is not multivalued nor are there multipart record keys on the file. Record counts are correct at all times.
Any ideas?
At 24 OCT 2001 10:29PM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
There were floating point operation fixes in AREV 2.12.
What happens if you start AREV with the /E (maths coprocessor emulation) option? Can't recall if that was
available in 1.16 but try it and see.
World Leaders in all things RevSoft
At 25 OCT 2001 10:57AM Victor Engel wrote:
Check to ensure the field contains numeric data. If there is a space, the value will not be added by R/List, but will by a human operator.
At 25 OCT 2001 11:28AM Warren wrote:
Not the problem.
Typical Sequence:
Run Report (incorrect total)
Run Again several times (incorrect total)
Run Again (correct total)
Subsequent runs (correct total)
No changes to data between runs.
No GFEs in file. No indexing, no quickdex.
At 25 OCT 2001 11:46AM warren wrote:
It should be there since REV G had it and back then math co-processors were optional
At 25 OCT 2001 11:57AM Victor Engel wrote:
Have you investigated what happens to the sizelock throughout this process? Perhaps if it's not being set correctly, records are being moved around during the LIST.
Actually, I vaguely remember encountering a similar problem on 1.16 back in 1990, but I don't remember what, if anything, we did about it. Out of curiosity (possibly related), how often do you get GFEs? Also, what is the use of the file like while running the report?
Have you tried summing up another column, say a symbolic whose formulat is @ans=1 to see if a record is being skipped completely or whether this is a math error?
At 26 OCT 2001 09:37AM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
Try dropping a FLUSH; GARBAGECOLLECT into your symbolics and
see if this improves things any. It may make string space
usage more predictable, if the problem is memory-related.
World Leaders in all things RevSoft
At 26 OCT 2001 02:54PM Don Miller - C3 Inc. wrote:
Since AREV 1.16 didn't support EMS, haveing sufficient conventional memory is paramount. If you have less than 370K+- conventional memory after AREV loads (use the WHO window) you can have the problems you describe. In fact many things will become unpredictable (windows sometimes not loading or loading with corrupt display, depending on the size of the record read). If you're using some variant of Windows, you will need to find as many ways of gaining conventional memory in the DOS box.
Go to an MS-DOS prompt and type MEM /C/P to check for the largest executable program size. If you don't have 560K as the largest executable, you will have problems with that version of AREV.
HTH
Don
At 27 OCT 2001 12:31PM Warren wrote:
EMS support was added in v1.13 if I recall correctly.
v1.13 and v1.16 were considered relatively 'clean' releases, again if I'm not mistake.
At least "WHO" in v1.16 shows EMS support.
Conventional memory optimization should have been done years ago but I'll recheck it. Difficult to do on some of the DR-DOS workstations.
Warren
Coming to the Web via Opera on OS/2 Warp 4.0!
At 27 OCT 2001 12:35PM Warren wrote:
We haven't had a GFE in over three years.
I tried the counter bit. I couldn't get it to fail the times I did try it.
At 27 OCT 2001 12:36PM Warren wrote:
It couldn't hurt. It might slow things down a bit on some of the floppy only 486 machines, but again shouldn't hurt.