Here is an update to this issue.

Instead of using APPEND FROM DBF('cursor') I used INSERT INTOs - no more missing data.

The problem is apparently related to the way COM is handled inside
of Windows 2000 or so I have heard. The temp work area is somehow being
altered - thus causing the erradict behavior. It is my understanding
from another VFP developer that Microsoft is aware of this behavior
and it will be corrected in the future.

>ALL ROWs get dropped. It is a straight unfiltered APPEND FROM (not FOR condition). I have an error routine but did not see it in there and of course purged it to keep things clean (wish I had not done that).
>
>I seem to recall there are situations where you not only need to SELECT a table but there do something like INKEY(.1) to let VFP catch up. Since this is all being done inside of a MTDLL it is much more difficult to trace.
>
>>Right then.
>>
>>So what is the nature of the problem in terms of missed data - all rows sometimes or last n rows sometimes or every second row sometimes or...?
>>
>>I assume to that your example is correct in that you do not use some filter condition in the APPEND FROM.
>>
>>Do you have an error routine that might be dropping (notification of) an error condition arising?
>>
>>good luck
>>
>>>It is NOT a filtered cursor rather it is a code CREATEd CURSOR that has its values populated from the web form then validated prior to adding all 15 rows of the cursor to the VFP table.
>>>
>>>>Tom,
>>>>
>>>>Is it possible that your "cursor" is NOT really a cursor, but rather a 'filtered result set'?
>>>>
>>>>If so, and you are using VFP6 or better, then the NOFILTER clause should fix that.
>>>>
>>>>If not, what records are you losing - all of them or just the last few or???
>>>>
>>>>good luck
>>>>
>>>>
>>>> >I have an application that is a MTDLL on a web site that saves 15 rows of data from a cursor to a permanent DBF table using the following commands:
>>>>>
>>>>>

>>>>>SELECT table
>>>>>APPEND FROM DBF('cursorname')
>>>>>

>>>>>
>>>>>I suppose the code would be better written as follows:
>>>>>
>>>>>

>>>>>SELECT table
>>>>>IF FLOCK()
>>>>>  APPEND FROM DBF('cursorname')
>>>>>ENDIF
>>>>>UNLOCK
>>>>>FLUSH
>>>>>

>>>>>
>>>>>The other alternative is to loop thru the cursor and do INSERT INTOs as such:
>>>>>
>>>>>

>>>>>SELECT cursor
>>>>>SCAN
>>>>>  SCATTER MEMVAR
>>>>>  INSERT INTO table FROM MEMVAR
>>>>>ENDSCAN
>>>>>

>>>>>
>>>>>I suppose the erradict data loss may be part of a contention issue but I find that somewhat unlikely (but possible) as this is not a heavily trafficed site.
>>>>>
>>>>>Anyone ever had a similar issue and what is the best solution - APPEND FROM or INSERT INTO?