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

[Nancy Palmquist]

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