Index problem

[John Esak]

Sorry Richard,

Not nearly enough info.  Or , at least, you are referring to things as if we
know them as you know them. For example, you say records are to be added
using a system?  You must mean something like records are added to this file
using a SYSTEM command somehow?  But how?  If so, does that SYSTEM call run
a process that somehow adds a record to this file?  That's all a little
vague. Also, the bit about doing a lookup from AUTO to check if there is a
record or not... Actually, can't tell anything from that other than it
sounds innocuous.

You say the program called enter is run from a menu command.  By this to you
mean it is run from a filePro menu command line that runs either a report
process or a clerk process that somehow adds a record?  Or do you mean a
menu command in processing where the user picks something off a processing
generated menu. All this is critically important to understanding what might
be going wrong, and you're leaving too much to our imagination.

My suggestion is to break down the main process for this file only  and show
the exact code that adds the records to it. Or, if they are only added
through that "enter" process, that code... And how it is called.

However, without hearing anything more, my gut feeling is the main problem
of corrupting an index (which is actually very hard to do in filePro) most
probably has something to do in or about the code you mention below.  

> My problem is that lately the primary key index is going bad. 
>  The program
> get the next tracking number from a master record and checks 
> the current
> file to see if that number has been used.

My very first thought is how in the world are you locking the retrieved
number long enough to do the test of its "uniqueness", then dealing with
that number whether it has or hasn't, and releasing and re-applying the lock
on the numbers record after you have either incremented it or not.  All this
sounds really slippery and the likely point in which users are retrieving
numbers you don't want them to get.  Still, I must admit I don't see how it
would corrupt an index built on numbers retrieved... No matter how you got
them.  I just think it's an important place to look when diagnosing this
issue.

Good luck.

John



> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com 
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
m] On Behalf Of Richard Kreiss
> Sent: Tuesday, May 25, 2010 12:29 PM
> To: filepro-list at lists.celestial.com
> Subject: Index problem
> 
> FP 5.6.10 windows, Server 2008
> 
> I have a file which adds records either using input 
> processing, which is
> called from a menu command and a program called enter.  Enter 
> us executed
> when the record is to be added from another file using a system.
> 
> My problem is that lately the primary key index is going bad. 
>  The program
> get the next tracking number from a master record and checks 
> the current
> file to see if that number has been used.
> 
> Both yesterday and twice today the index had to be rebuilt.  
> This causes a
> problem as the primary marketing file access information from 
> this file and
> no records can be added to this file.
> 
> The error message is lookup failed on line NN (either 176 for 
> input or 79
> for enter).
> 
> Any suggestions as to what might cause this problem.  There 
> is no data being
> posted to this file from anywhere other than the file itself. 
>  The only
> lookup is in auto processing of the marketing to set a  
> yes/no variable if a
> record exists in this file.
> 
> All update after a record has been added is from a menu 
> command to that
> file.
> 
> 
> Richard Kreiss
> GCC Consulting
> rkreiss at gccconsulting.net
>   
> 
> 
> 
> 
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>