Sometimes the implicit (or batch) functions like "append from" and "insert into" produce unexpected results. A few versions back (and it may be true now), the append from required locked files. I had some issues with "scan", but cannot recall the specifics.

When the implict guys are not producing, this tedius (yet speedy) explicit syntax always seems to work:

select myOutput
zap
select myInput
go top 
do while !eof()
select myOutput
append blank
replace field_1 with myInput.field_1, field_2 with myInput.field_2 ;
 in myOutput
select myInput
skip
enddo

This one seems to always gets the data where it's wanted.

>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?