Slow issue with filepro on Windows 2003 / XP clients - Just Started

[Richard Kreiss]

Nancy,

Had a similar problem with a logfile that tracked changes to fields with the
original data, the new data, who, date time and what process.  Periodically
the indexes would cause the programs to lockup.

Although john suggested it test each of the 4 indexes separately until I
found the one causing the problem, I had an easier solution.  Since the file
was rarely accessed by IUA, and if it was accessed, management would be
looking for information prior to the current day.  I replaced the auto
indexes with demand indexes.  They have the skills to use selection sets to
get at the information they are looking for.  This eliminated the problem.  

These indexes are rebuilt each night.

I have a feeling the problem may have been a large number of blank fields as
part of the primary sort.

This client is have some performance issues, Windows server 2008 and XP.
The staff in the office is running much slower the outside staff who
terminal server in.  I am talking about 8 seconds to load a file inside
against 3 seconds with terminal server.  Once loaded, performance is about
the same.  This is not AV issue and the network hardware has been checked
for problems.

Oh well, so goes the world of computers and programming.

Richard

PS: Wait until you try to solve problems which "Cloud Computing". :)



> -----Original Message-----
> From: filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com
[mailto:filepro-
> list-bounces+rkreiss=verizon.net at lists.celestial.com] On Behalf Of Nancy
> Palmquist
> 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
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list