Slow issue with filepro on Windows 2003 / XP clients - JustStarted

[John Esak]

Sorry, been out of town a bit... And today I woke up feeling a sore
throat.... So I stayed away from email and everything for awhile.

I'm glad you solved the basic hasssle... But it sure irks me when I hear
people goig through that "memory blah blah" thing that seems to lodge
directly on one particular line of code... And is affected by other things
interspersed, etc.   The WRITE QUE thing must be so annoying. I'm curious
about two things. If you removed the two indexes in the file being written
(que) would it still trhow the error?  In other words just writing to the
key?  And is the record itself a newly added record from some sort of a
lookup free in clerk?  Other than things relaated to these two things, I
have no answers for the errant memory problem.  This by the way has nothing
to do with anything, but one of my last ditch things to try when I'm getting
squirrely effects and dumps and strangeness ... Is to check the value of
PFLBSIZE. If it isn't large enough I've seen completely weird behavior, and
maybe even Memory this and that. I know for the complexity of tables you
write, the default is WAY too low.  Jack it up very high, 8192, 10,000, see
if it has any effect.

Good luck,

John


> -----Original Message-----
> From: Nancy Palmquist [mailto:nlp at vss3.com] 
> Sent: Thursday, January 07, 2010 9:45 AM
> To: john at valar.com
> Cc: 'filePro List'
> Subject: Re: Slow issue with filepro on Windows 2003 / XP 
> clients - JustStarted
> 
> John,
> 
> Only one index in question had a second sort, the other two did have 
> subsequent sorts.  We did not test to see if just the single 
> sort index 
> was the problem.  Might have been that simple. 
> 
> I really hate indexing something like a yes/no flag that 
> jumps back and 
> forth.  I really have had big problems with those kinds of 
> indexes.  I 
> wish there was some tool in filePro that could tell you if an 
> index is 
> getting in trouble.  Not sure what it would do, but it sure would be 
> nice.  I am really tired of tracking down index problems.
> 
> We rebuild the heavily used indexes every night to try to 
> avoid issues.  
> We spent two days this week trying to find a solution to 
> something that 
> just started - for no apparent reason.  Looking at virus software, 
> hardware issues, collecting information about what processes were 
> different and what was not.  We were narrowing down to one 
> file that is 
> used by 80% of the workers.  We sat them idle for 3 hours or 
> more while 
> we ran freechain and index rebuilds to try to fix the problem.
> 
> It really hurt the company productivity.  I designed the file to hold 
> history for a few months.  Since then I wrote logic to find 
> the checks 
> even in an archive file, if they needed reference, so there was no 
> reason not to archive some of the stuff.  As it is, they kept 
> 6 months 
> of checks, still twice what was planned when we designed the 
> project.  
> We removed at least one year to get to a point where it seems to work 
> properly again.
> 
> Now if I could solve the issue with the intermitten memory errors on 
> another file, we would be golden.  This issue returned right after we 
> solved the index issue.  I have chased down everything I can 
> think of on 
> this file and the fact that it works without issue for months 
> and then 
> for a few days it crashes and crashes on exactly one command:
> 
> WRITE QUE
> 
> The write to a particular file.  I got it right to a 
> particular command 
> and actually it is only updating 2 indexes with this write since the 
> data I changed affects only two indexes.  They are fresh built every 
> night.  But when this happens we know the index will report 
> deleted key 
> errors and it all seems to cascade after that first crash.  Can not 
> reproduce the problem since there are more than 20 people 
> updating data 
> to this file and a few others adding data in big batch 
> processes to this 
> file during the day. The indexes get a real workout.  The two 
> that crash 
> really track the status of the order.  The other indexes 
> pretty much are 
> just changed when the order is added and then do not change 
> for the life 
> of the order.
> 
> I hate this index stuff.  Well I am done venting - got to get 
> real work 
> done.  Hopefully I can concentrate on programming and not 
> chasing memory 
> errors for the rest of the week.
> 
> Great to hear from you John.  Hope life is treating you well.
> Nancy
> 
> 
> 
> John Esak wrote:
> > Thanks for the solution. I was wracking my brain for some 
> suggestions.  Glad
> > you figured it out. I do what you do with indexes that have 
> duplicate keys
> > in most of the records.  I add a second key that will be 
> unique itself, like
> > @rn. 
> >
> > John
> >
> >   
> -----Original Message-----snipped
> 
> -- 
> Nancy Palmquist 		MOS & filePro Training Available
> Virtual Software Systems	Web Based Training and Consulting	
> PHONE: (412) 835-9417		   Web site:  http://www.vss3.com
>