Stefan,

Your code may produce incorrect result if SET NEAR set to ON. It's better to use FOUND() function which isn't affected by such seting.

   if NOT FOUND([stock_previous])  && new record -> insert
...

Also, I'm unaware of SCAN...ENSCAN locking any records and there's nothing in the help abput that. Can you provide some code that proves your statement?

>In this particular case you can get away with a slight modification to your SCAN loop:
>
>

>select stock
>set order to number in stock_previous
>set relation to number into stock_previous
>* note: the FOR condition covers EOF([stock_previous]) implicitly
>scan for stock.units <> stock_previous.units
>   if eof([stock_previous])  && new record -> insert
>      insert into stock_previous ...
>      insert into stock_remote ...
>   else && unit count out of date -> update
>      replace units with stock.units in stock_previous
>      update stock_remote ...
>   endif
>endscan

>
>Note, however, that this loop will not detect orphaned records (that is, records that have been deleted in the master table but that still exist in the replicas). The easiest way out is to decree that unit count be set to 0 instead of deleting records. If that is not possible then you need to walk the stock and stock_previous tables in tandem or do the orphan detection separately (SQL select).
>
>Also, the pairs of update/insert statements should be protected by a transaction because the integrity of your data depends on stock_previous being a faithful 'shadow' of stock_remote.
>
>P.S.: you may want to use a DO WHILE loop instead of a SCAN loop because SCAN seems to do some aggressive locking; DO WHILE in connection with SKIP seems to be more multi-user friendly.