Anna_BuchДва пользователя подключаются к базе данных. Первый открывает справочник товара, заходит на корректировку строки, в каком-нибудь поле textbox начинает вводить информацию. Второй пользователь в это время пытается зайти в этот же справочник товара, но программа подвисает на команде: repl all pr_v&v with 0 на init формы. Пока первый не закончит ввод в textbox, у второго все висит.
Подобное происходит в разных местах программы, где есть аналогичная ситуация. Сама программа была когда-то локальной, потом ее переработали под сетевую самым минимальным способом: убрали команды, требующие эксклюзивного доступа, организовали рабочие файлы для каждого пользователя в отдельные папки. Короче, она уже много лет работала, но оказалось, что было всего 2 пользователя, которые не особо пересекались на вводе информации. Теперь добавился третий пользователь и вылезло то, о чем никто не подозревал. Подскажите, пожалуйста, что можно предпринять?
В общем, дело, разумеется, в блокировках.

1. Первый пользователь начал редактировать запись и заблокировал ее
2. Второй пользователь "бесконечно" ждет снятия блокировки с записи, чтобы внести в нее изменения

Варианты действия у Вас следующие

1. Переделать программу с тем, чтобы процесс редактирования записи не приводил к ее блокировке
2. Переделать программу с тем, чтобы не требовалась глобальное обновление всех записей таблицы
3. Перед глобальным обновлением записей таблицы попытаться вручную наложить блокировку

Насколько я понимаю, первые два варианта для Вас в настоящее время не приемлемы. Тогда остается только третий вариант, как некая "затычка". Делается это примерно так

Anna_Buchpr_v1, prv2, и т.д. это поля, куда заносится 1, когда пользователь ставит птичку при выборе товара. их по-любому нужно когда-то чистить. ну , если снимать пометку сразу после выбора товара, от этого можно избавиться.
Как уже заметил Сергей, использование постоянных таблиц для хранения временных данных (в данном случае "птичек") крайне не удачное решение. "Птички", очевидно, должны ставится в каких-то временных данных.

Идеальное решение - это выборка с дополнительным полем (Local View, CursorAdapter, Select-SQL). Решение несколько хуже - временная таблица (курсор), которая создается в момент открытия формы и содержит только два поля: идентификатор записи и поле для "птички". Еще одно решение - табличная буферизация. Перед сбросом буфера откатить все "птички"

Однако, как Вы понимаете, все эти решения требуют серьезной переделки приложения.

Anna_Buch а как быть в других местах с аналогичной ситуацией,
Каждый случай требует отдельного рассмотрения.

Anna_Buch напр. когда удаляются записи из того же справочника в специальное поле pr_del заносится цифра 2, чтобы потом при упаковке эти строки удалить. так вот это тоже происходит при помощи команды repl all for или scan for. и на этом месте тоже висит.
Это как? Групповое удаление записей в справочнике? В смысле, Вы цифру 2 ставите через replace all? Как-то у меня воображения не хватает на такое

Если же речь идет о последующем физическом удалении, так этот процесс требует монопольного доступа. Конфликт с другими пользователями невозможен.

Anna_Buchя вот не пойму, это зависание что, стандартная ситуация? так вообще никто не делает?
Никто. При написании приложений, с которыми одновременно могут работать несколько пользователей, всегда используется, так называемая, оптимистическая буферизация. Либо "самопальная" (на курсорах или переменных памяти) или стандартная - cursorSetProp("Buffering").

Основная идея заключается в том, чтобы разделить процесс редактирования данных пользователем и собственно сохранение внесенных изменений в таблицах.

Т.е. пока у пользователя открыта для редактирования форма, данные никак не блокируется. Пользователь вносит изменения в некий "буфер данных". Можете считать это некой прозрачной "калькой" положенной на лист с данными. И пользователь "чиркает" именно эту "кальку".

А вот когда пользователь завершил процесс редактирования и, условно, нажал кнопку "Сохранить", то только в этот момент данные блокируются и в них переносятся все изменения с "кальки" (из буфера).

В результате, собственно блокировка данных всегда занимает крайне незначительное время. Даже если два пользователя "одновременно" нажали кнопку "Сохранить", но ждать им придется не очень долго.

Разумеется, при подобной стратегии возникают конфликты совместного доступа (два пользователя изменили одни и те же данные). Но как их решать зависит уже от конкретной постановки задачи. Проблема носит не столько технический, сколько организационный характер.