Slow issue with filepro on Windows 2003 / XP clients

[Boaz Bezborodko]

>
> Date: Thu, 07 Jan 2010 09:45:24 -0500
> From: Nancy Palmquist <nlp at vss3.com>
> Subject: Re: Slow issue with filepro on Windows 2003 / XP clients -
> 	JustStarted
> To: john at valar.com
> Cc: 'filePro List' <filepro-list at lists.celestial.com>
> Message-ID: <4B45F384.1050503 at vss3.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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

Nancy,

I experienced the "deleted key" error on a program I was developing a 
few days ago.  I'm not sure I remember exactly what was the problem, but 
I remember that it had something to do with WRITEing the data (WRTIE 
<file>) to that file and then looking to add something else to it and 
WRITEing again.  In between I was testing to see if the file was open 
(IF: <file>) before the next WRITE operation.  In between something else 
was able to delete the record because it was no longer locked and the 
result was the "Deleted key" error.  The answer was to either re-protect 
the record with another lookup or completely closing the lookup file 
after the WRITE and re-opening with another lookup.  Either way I had to 
protect the record from a deletion from elsewhere in the system.

Using WRITE has the problem of keeping a lookup file open in the 
existing users' table while removing the protection for the record to 
other users.  So a test of "IF: <file>" or "IF: not <file>" will still 
show "TRUE" for a file even if no record is open on it.

I'm not sure if this is related to your problem or not, but it puzzled 
me for a bit before I realized what was going on.

Boaz