index problem

[Ken Cole]

Richard,

I did not see what version of FP you are using in this instance but I have
seen in several instances indexes based on a 1 character field, which of
course can create many many duplicate index keys as many many records have
the same value, do "funny" things.  I can even remember a fix for this in
one of the later releases if my memory serves me correctly.  Add some extra
fields to the index even if not required just to make the keys more "unique"
and have less duplicates and see if that helps your issue.

Jeff's last suggestion of redoing the lookup once the key value is changed
is also a good suggestion that I can concur has solved some issues
previously.

Cheers

Ken

On Tue, Feb 22, 2011 at 7:45 AM, Jeff Harrison <jeffaharrison at yahoo.com>wrote:

> ----- Original Message ----
>
> > From: Richard Kreiss <rkreiss at gccconsulting.net>
> > To: Jeff Harrison <jeffaharrison at yahoo.com>
> > Cc: filepro-list at lists.celestial.comf
> > Sent: Mon, February 21, 2011 10:40:29 AM
> > Subject: Re: index problem
> >
> > Quoting Jeff Harrison <jeffaharrison at yahoo.com>:
> >
> > >  ----- Original Message ----
> > >
> > >> From: Richard Kreiss <rkreiss at gccconsulting.net>
> > >>  To: filepro-list at lists.celestial.comf
> > >>  Sent: Sun, February 20, 2011 12:15:09 PM
> > >> Subject: index  problem
> > >>
> > >> A client has been having an index problem after  a status field value
> > >> is changed.
> > >>
> > >> The record  is accessed from a browse lookup by getting  the record
> > >> number  and then doing a
> > >>
> [snip]
>
> > >
> > > It is  difficult/impossible to tell why your index is getting corrupted
> >without
> > >  seeing all of the pertinent code.  Are you locking the record before
> the
> >status
> > > is updated?  Are your doing a write or close to that  protected lookup
> when
> >you
> > > are done?   When doing something like you  describe, I would do the
> protected
> > > lookup, change the data, then close  the file.  After returning from
> the
> >called
> > > process I would have it  re-execute the original browse based on the
> new
> >data.
> > >
>
> > Jeff,
> >
> > The program is updating the current  record and was accessed using @keyS.
> >
> > @keyS initiates the sales  routines.It is the index in this "local" file
> which
> >is having the problem.   The @key locks the record.
> >
> > I noticed that I had put a write in in the  called routine just before it
> >returns to the calling input  program.
> >
> > Richard
> >
>
> Again, it is difficult/impossible to say without seeing all of the
> applicable
> code.  Can you isolate this so that it is duplicatable with minimal code?
>  Then
> perhaps you can post all of that code and we can take a look.
>
> Jeff Harrison
> jeffaharrison at yahoo.com
> Author of JHExport and JHImport
>
>
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20110222/fa925de7/attachment.html