index problem

[Richard Kreiss]

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

989  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
sho_rec? If:                                                            
         ?
        Then: lookup -  r=rn   -npw                                     
          ?
990  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
        ? If: locked(-)                                                 
          ?
        Then: MSGBOX "Someone Else is Updating this Patient  
Record";GOTO brw_new?
991  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
        ? If:                                                           
          ?
        Then: display(@sn);start_call=@tm                               
          ?
992  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
        ? If:                                                           
          ?
        Then: END                                                       
          ?

If a sales is generated, a processing table is called to complete the  
operation.  Just before the processing table ends, the fields  
status_sales, field 25, is changed to a 6.  The called table ends  
returning the user back to the calling program and the original browse  
lookup with the cursor on the next name.

Lately, but not always, they get a message to rebuild index O which  
has the primary key the status field.

All updates to the record are done using @key functions.

Would a write at the end of the called table avoid this problem?

Richard Kreiss
GCC Consulting