Problem with dreport crashing

[GCC Consulting]

> -----Original Message-----
> From: filepro-list-bounces+gccconsulting=comcast.net at lists.celestial.com
>
[mailto:filepro-list-bounces+gccconsulting=comcast.net at lists.celestial.com]
On
> Behalf Of Chris Sellitto
> Sent: Friday, August 01, 2008 11:15 AM
> To: filepro list
> Subject: RE: Problem with dreport crashing
> 
> 
> 
> > -----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

Not aware of any utility.  However, if the warehouse is not operating around
the clock, you could run a rebuild option at night. 

Depending what OS this would either be a cron job or through task manager on
Windows.

Depending on the version of fp you have, you might have an index maintenance
program supplied with your fp install or upgrade.

Look to see if you have these 2 files fpidx and fpidxdat.  If you haven't
used these programs yet, through IUA load fpidx. At the prompt answer (Y)es.
The program will examine all of the indexes in your application and copy the
command line necessary to rebuild each index to a record in fpidxdat.  The
program will also build a batch file, fpreindx.bat -windows or
fpreindx.sh-*nix.

Now just set either run a cron or task to run this file at night.

Richard

PS: remember to re-run fpidx when you add or change indexes.