>>>>>>>>>Is there a reason that you are not using "INSERT INTO tablename ..." to add records?
>>>>>>>>
>>>>>>>>Hi Larry, have not heard from you in a while...
>>>>>>>>I am using APPEND BLANK with table buffering, is it preferably to use INSERT INTO with table buffering?
>>>>>>>>:)))))
>>>>>>>
>>>>>>>insert into is preferrable almost all the time
>>>>>>
>>>>>>especially assuming multiple manipulations with buffering, etc.:)
>>>>>...yeah...what they said! //:^)
>>>>>Still having problems with the dups. I know that there are bugs using table buffering. I dont recall specifically what they are, but nevertheless I dont like table buffering because it consumes a lot of network and work station resources (from what I understand). Unless you are adding multiple records (child records) that may need to be "undone" then you should try to stay with record buffering. //:^)
>>>>I took care of the dups.. In the UNLOAD event, I coded:
>>>>scan empty(field_name)
>>>> blank
>>>> delete
>>>>endscan
>>>>
>>>>When I add, I scan for deleted() and recall.
>>>>Just like to you showed me... :))))))
>>>When you scan (or locate) for deleted you have your indexes turned off, dont you? (SET ORDER TO 0)
>>No - I have not been using SET ORDER TO 0 - Am I suppose too?
>Only if you want to find the record as fast as possible. If you dont, you have what amounts to a "battle of the indexes", while rushmore is trying to search thru the indexes you have, the display portion (or its equivalent) is trying to keep it ordered with the current set index. Once you locate the record then you can reset the index order you desire before you display (browse) the information. Actually if you want it to be as fast as possible use..
>
>SET DELE OFF
>SET ORDER TO ISDELETED
>IF SEEK(.T.)
> RECALL
> GATHER MEMVAR
>ELSE
> INSERT INTO tablename FROM MEMVAR
>ENDIF
>
>or something similar... //:^)
thanks Larry - I got the idea... :))