index problem

[Richard Kreiss]

Ken,

Windows 5.6.10
Server 2008 64 bit
Local: Win xp pro
Remote: Terminal server Windows 2008 64 bit

Richard

-----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 Ken Cole
Sent: Monday, February 21, 2011 6:05 PM
To: filepro-list at lists.celestial.com
Subject: Re: index problem

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/fa9
25de7/attachment.html
_______________________________________________
Filepro-list mailing list
Filepro-list at lists.celestial.com
Subscribe/Unsubscribe/Subscription Changes
http://mailman.celestial.com/mailman/listinfo/filepro-list