index problem

[Jean-Pierre A. Radley]

Richard Kreiss propounded (on Sun, Feb 20, 2011 at 12:15:09PM -0500):
| 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?

[KenBrodyMode]

What happened when you tried it?

[/KenBrodyMode]

-- 
JP