Elmer,

MyTable is a physical table with no buffering. I even commented out the processing code, rebuilt all the table indexes and still get the same results.

Thanks for your time and input Elmer.

>Is MyTable a view or a physical table? If a view, what is the buffering mode? I'm not sure off the top of my head how uncommitted inserts will behave in a scan loop. If buffered, the new records will have negative record numbers until tableupdate. If a table and not buffered, I'm about out of ideas, sorry.
>
>>Elmer,
>>
>>Sorry I tried to cut down on the amount of code and left out some important parts.
>>
>>There are GO statments after each INSERT and no index on MyTable. It does have relationships set as follows but MyTable is the parent table:
>>
>>

>>USE OurTable ALIAS MyTable SHARED
>>
>>SELECT link_id,tran_code,activity,CNT(*) FROM MyTable ;
>>  WHERE !EMPTY(link_id) AND part_num<>'000000000' AND !EMPTY(gl_ind) GROUP BY 1 INTO CURSOR moa_link
>>INDEX ON link_id TAG link_id
>>
>>SELE MyTable
>>SET RELA TO ALLT(MyTable.SOURCE)+ALLT(MyTable.ulob_co)+ALLT(MyTable.ulob_lob)+MyTable.tran_code+;
>>  IIF(MyTable.pend_stat$'R,X' AND VAL(MyTable.assoc_act)<>0,;
>>  MyTable.assoc_act,MyTable.activity) INTO otran
>>
>>SET RELA TO link_id INTO moa_link ADDITIVE
>>
>>SELE otran
>>SET RELA TO ALLT(MyTable.SOURCE)+PADL(ALLTRIM(STR(cat)),6,"0")+UPPER(ALLTRIM(MyTable.fund_type)) INTO htran
>>
>>SET RELA TO ALLT(MyTable.SOURCE)+PADL(ALLTRIM(STR(cat)),6,"0")+'ANY' INTO htran1 ADDI
>>
>>SELECT MyTable
>>SCAN
>>  SELECT MyTable
>>  SCATTER TO laArray
>>  _currec=RECNO()
>>  IF !EMPTY(MyTable.link_id) AND !MyTable.moa_flag AND !EMPTY(MyTable.gl_ind)
>>    FOR x=1 TO 9
>>      DO CASE
>>        CASE x=1 AND ...
>>          laArray[22]=laArray[22]+"SA"
>>          INSERT INTO MyTable FROM ARRAY laArray
>>          GO _currec
>>
>>        CASE X=2 AND ...
>>          laArray[22]=laArray[22]+"GA"
>>          INSERT INTO MyTable FROM ARRAY laArray
>>          GO _currec
>>
>>        CASE x=3 AND ...
>>          laArray[22]=laArray[22]+"MF"
>>          INSERT INTO MyTable FROM ARRAY laArray
>>          GO _currec
>>
>>      ENDCASE
>>    ENDFOR
>>    RELE laArray
>>    REPLACE MyTable.processed WITH .T.
>>    LOOP
>>  ENDIF
>>
>>*** Process and distribute MyTable to other tables
>>
>>
>>*** After processing of MyTable
>>
>>  SELE MyTable
>>  DO CASE
>>    CASE !processed AND _inhtran
>>      REPLACE MyTable.processed WITH .F.,RULE WITH '97'
>>
>>    CASE !processed AND !_inhtran
>>      REPLACE MyTable.processed WITH .F.,RULE WITH '74 Fund not in matrix'
>>
>>  ENDCASE
>>ENDSCAN
>>

>>
>>>>While investigating some scary VFP code for a data production problem I came across the following :
>>>>
>>>>

>>>>SELECT MyTable
>>>>SCAN
>>>>  SCATTER TO laArray
>>>>  FOR x=1 TO 9
>>>>    DO CASE
>>>>      CASE x=1 AND ...
>>>>        laArray[22]=laArray[22]+"SA"
>>>>        INSERT INTO MyTable FROM ARRAY laArray
>>>>
>>>>      CASE X=2 AND ...
>>>>        laArray[22]=laArray[22]+"GA"
>>>>        INSERT INTO MyTable FROM ARRAY laArray
>>>>
>>>>      CASE x=3 AND ...
>>>>        laArray[22]=laArray[22]+"MF"
>>>>        INSERT INTO MyTable FROM ARRAY laArray
>>>>
>>>>    ENDCASE
>>>>  ENDFOR
>>>>
>>>>*** Process MyTable
>>>>
>>>>ENDSCAN
>>>>

>>>>
>>>>The cause of the problem is the records INSERTED during the scan are never processed. Walking through the code in the DEBUGGER shows the MyTable hits EOF when on the record that was the last record when the SCAN started. I could reproduce the problem VFP 8 and VFP 9 earlier this week at the office. Support is upgrading production code to VFP 8.0 so I thought it was a upgrade problem but they assured me the problem began BEFORE the upgrade was put in place. Well tonight I just ran the same code in VFP 6 SP5 thinking it would work but that is not the case. Walking through the DEBUGGER I get the same results as I do in VFP 8 and VFP 9.
>>>>
>>>>The troubling part is this code has been running and working in a high-volume, production environment since 2000. The problem started on November 8th and production support has not been able to solve the problem so I was asked me to investigate.
>>>>
>>>>Maybe VFP 6.0 worked before installing the VFP 8.0 runtimes? I don't know all the update details of when, what and who yet.
>>>>
>>>>Any ideas?
>>>>
>>>>Thanks!
>>>
>>>Is there an index order set? Are the inserted records being inserted into the table inserted at a position that has already been processed?
>>>
>>>If no index order is set, check to see if the insert is changing the record pointer to the last record that was inserted? In my quick test when I insert a record in the scan loop, it moves the record pointer to the last record inserted which short circuits the loop causing it to exit without processing any other record after the insert. It behaves like issuing go bottom within the scan loop But if I save the record number prior to the insert, then return back to that same record after the insert, it processes all records including the newly inserted records. Unfortunately this will not work if there is an index order set since the inserted records may be placed in the index order before the last record processed in the scan.
>>>
>>>I suggest checking your loop to determine if the insert is changing the record pointer.