Ув. коллеги!
Уже четыре года я наблюдаю и пытаюсь бороться с ситуацией :
При использовании комманды
REPLACE поле1 WITH значение1, поле2 WITH значение2 IN алиас_таблицы
происходит сбой в обработке и по нескольким записям не производится замена значения, кол-во необработанных коммандой записей в таблице ориентировочно
для одной сессии пользователя варьируется от 1-2 на 300-500 до 1-2 на 1000-5000.

Пример кода:

SET ORDER TO NOMDOC IN m_oper - (вариант2)
m.maxSum = 1 000 0000.00
m.Data = {^2000/01/01}

SELECT m_oper
DO WHILE SEEK(m.newNomdoc,'m_oper','NOMDOC') - - (вариант1)
SEEK(m.newNomdoc,'m_oper') - (вариант2)
IF (m.summa + (m_oper.kolvo*m_oper.cena1)) < m.maxSum
m.summa = m.summa + (m_oper.kolvo*m_oper.cena1)
REPLACE NOMDOC WITH m.NOMDOC, TO WITH m.member IN m_oper
ELSE
m.summa = (m_oper.kolvo*m_oper.cena1)
m.Data = m.Data + 1
m.datadoc = m.Data
REPLACE NOMDOC WITH m.NOMDOC, TO WITH m.member IN m_oper
ENDIF
ENDDO

Режим работы многопользовательский - 65 пользователей заносящих изменения в
таблицы 45 - читающие информацию.
Проводились экперементы по блокированию записей перед заменой, по блокированию таблиц перед заменой (принудительный сброс буферов)- результат ОДИНАКОВ !!!
Моё субъективное мнение - Неуспевают обновляться индексные файлы и пользователь пытаясь заменить значение просто не находит этой записи если другим пользователем была произведена модификация данных даже не этих записей.Ещё влияющим фактором может быть большие размеры таблиц:
файл DBF - 1,35 ГБ (1 457 991 680 байт)
файл CDX - 679 МБ (712 876 032 байт)
*----- ЕСЛИ КТОТО СТАЛКИВАЛСЯ ИЛИ ПРЕДПОЛАГАЕТ ЧТО ЛИБО ПИШИТЕ ------

Станислав C.

Что-то я никак не разберусь в закодированном алгоритме. Опиши его человесческим языком, пожалуйста.

Комментарий:
Если Seek не находит заданную запись, то он либо встает на ближайшую похожую, либо на конец файла (в зависимости от установки SET EXACT...)
А если находит, то очень похоже, что произойдет зацикливание. При том, будет идти работа только с одной записью, так как seek находит первую запись удовлетворяющую условию (как, впрочем, и другие команды поиска...)
Может быть в этом причина твоих "бед"?

Это он делает когда правильно отрабатывается. Находит или не находит, а вот что получается реально :

исходные данные m_oper

NOMDOC KOLVO CENA1 MEMBER
00000001 1 1000.00 00001
00000001 3 1004.00 00001
00000001 1 1070.00 00001
00000001 8 1112.00 00001
00000001 1 9999.00 00001
00000001 2 6666.00 00001
00000001 1 1111.00 00001
...

после отработки реплейса

NOMDOC KOLVO CENA1 MEMBER
00000002 1 1000.00 00002
00000002 3 1004.00 00002
00000001 1 1070.00 00001
00000002 8 1112.00 00002
00000002 1 9999.00 00002
00000002 2 6666.00 00002
00000002 1 1111.00 00002
...
Это один из вариантов иногда не изменяется значение только в одном поле по
записи, т.е. NOMDOC - изменился, а MEMBER - нет.

Это кусок кода.
Переменные работают так:
m.NewNomDoc - фиксированное значение.
m.NomDoc - текущее значение поля в таблице m_oper
m.member - фиксированное значение.
m.summa - в начале (m.summa=0)
*--------------------------------------------------------------------

Увы уникальный идентификатор использовать немогу. :(
А по поводу замены поля при активном индексе по нему я знаю, поэтому перебор
устраивался всеми возможными методами. В данной конструкции возможно
применение SCAN ... ENDSCAN НО!!!!! - по времени обработки очень долго.
Поэтому пришел к алгоритму
устанавливаем индекс.
находим по индексу значение.
делаем замену по полям.
... повторяем.

*-------------------------------------------------------------------

Отвлёкся !!! Проблема ведь в том, что при любых конструкциях с REPLACE
наблюдается тенденция - некоторые поля не изменяются.