Problem with dreport crashing

[Chris Sellitto]

> -----Original Message-----
> From: 
> filepro-list-bounces+sellich=guaranteedreturns.com at lists.celes
> tial.com 
> [mailto:filepro-list-bounces+sellich=guaranteedreturns.com at lis
> ts.celestial.com] On Behalf Of Bruce Easton
> Sent: Friday, August 01, 2008 1:47 AM
> To: filepro list
> Subject: Re: Problem with dreport crashing
> 
> Quoting Nancy Palmquist <nlp at vss3.com>:
> > 
> > Bruce Easton wrote:
> > > Nancy Palmquist wrote Thursday, July 31, 2008 4:37 PM:
> > >
> > > [a bunch of good stuff about things to watch out for on 
> Windows with 
> > > filepro (if rats were filepro developers, they would be 
> eating their 
> > > young at this point), including ..]
> > >   
> > >> Then I increased the TOK size for all TOK levels, that 
> put me up to 
> > >> 99.9% reliability.
> > >>
> > >>     
> > > [and ..]
> > >
> > >   
> > >> 2) Check TOK sizes - increase if not sure.  defaults are 
> 20000 for
> > each
> > >> of the three types.
> > >>
> > >>     
> > >
> > > I was a bit surprised when I ran that little test a while 
> ago (Unix 
> > > fp 5.0.14) where it said at runtime my token table for the called 
> > > table was too small when all it had in it was:
> > >
> > > ::1="333":
> > > ::write:
> > > ::end:
> > >
> > > (field 1 was a ten character field and the map only had that one 
> > > field in it; also only one index for the file against that one 
> > > field)
> > >
> > > Isn't there a minimum tok size for form/called prc in use if not 
> > > set?
> > >   
> > 
> > Default is 20000.  You can decrease to 10000. Tok size is not a 
> > measure
> > 
> > of the size of the processing only, in includes arrays and 
> variables.  
> > Is it possible the machine did not have enough memory to 
> allocate the 
> > minimum?  Tok size might be for automatic processing, input 
> processing 
> > or form processing (calls are using the same memory as 
> forms, chains 
> > use
> > 
> > the same memory as input or output.)  When you are 
> Requesting Output 
> > the
> > 
> > form processing is the same as INPUT and the calls use the form 
> > processing.  So is it possible that the automatic 
> processing was the 
> > issue or a form that printed.
> > 
> > Nancy
> > 
> 
> No - for this test case, I specifically only used that small 
> processing above as a as a called prc (from a report 
> selection processing that only hadthe call to this prc); no 
> final output processing; no auto prc.  Blank report format.
> I know this for sure
> because I created the test file from scratch just for this 
> test and I only create the lines above plus the one line "call testc" 
> selection table.  Now granted, I probably would never use a 
> table like this - and ultimately, with no select statement, 
> no records were selected for output, so it did the call while 
> reading records. 
> 
> Maybe that does have some merit as Mark is doing - a place to 
> process in report  on one record without selecting any 
> records and therefore not ever opening spooler?  I'll have to 
> think on that at a better hour.
> 
> When I set the -tf size to 30000, the problem went away.  
> That's why I thought it was strange that such a small table 
> with small map, index and byte use would throw up that error.
> 
> Bruce
> 
> Bruce Easton
> STN, Inc.
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list


All,

Today (08/01/08), I came into the office bombarded with an entire
warehouse of people with the "Memory Could Not Be Read From" error.  I
noticed it was happening basically at the same point in the program
every time.  So I checked the file that it was updating, and rebuilt the
indexes, and that resolved this particular issue.

Based on what I have been reading, it seems that the majority of the
time, this error is triggered by a bad index.

My question is, is there a utility out there that could be run manually,
that might somehow recognize that an index is bad?  Is it even possible,
and if so, does anyone know how to write one?



Christopher Sellitto
VP Computer Operations
Guaranteed Returns
100 Colin Drive
Holbrook, NY 11741
(631) 689-0191 x132
sellich at guaranteedreturns.com