BurnСудя по всему у Вас 3-я буфферизация если сброс происходит автоматически при переходе от строки к строке. Ставте 5-ю. Хотя это все равно не гарантирует от проблем с кандидат индексом.
Если перешли на схему непосредственого ввода в Грид то проверяте поля по мере ввода - либо Valid/LostFocus теккстбоксов в колонках гридов или AfterRowColChange грида
Это не поможет. Контроль индекса осуществляется еще ДО сброса буфера. По факту заполнения записи. Т.е. и в табличном режиме буферизации будет выскакивать сообщение об ошибке при попытке перейти на другую запись.

Единственный вариант в данном случае - это ручной перехват системной ошибки в событии формы Form.Error() или в аналогичном событии Grid.Error(). Код ошибки 1884.

Проблема только в том, что если есть несколько индексов типа Candidat, то нет возможности однозначно определить, какой же из них вызвал ошибку.

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

Как эту копию организовать - через CursorAdapter, Local View, набор переменных или каким-нибудь еще способом - не важно. Важно, что работа будет осуществляться не с самой таблицей-источником (пусть и буферизированным), а с другими данными.

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

Другой вариант - это организовать контроль уникальности не через индекс, а через триггер на вставку. Вот триггер будет срабатывать только в момент сброса буфера. При определенных стандартах создания структуры базы данных можно написать универсальный (в рамках данной базы данных) триггер на контроль уникальности введенных данных.

Galyamov Rinat
> Единственный вариант в данном случае - это ручной перехват системной
> ошибки в событии формы Form.Error() или в аналогичном событии
> Grid.Error(). Код ошибки 1884.

Перешел на строковую буферизацию с принудительным сбросом буфера в событии
beforerowcolchange


Такой же механизм при попытке закрытия формы (т.е. самой таблицы)

При таком раскладе сообщение не выскакивает, а можно обработать через
четвертый параметр ф-ции tableupdate (пока еще не сделал)
На практике, это единственно возможный способ работы, в случае прямой модификации данных в Grid. Ведь признаком завершения модификации как раз и является попытка перехода на другую запись. Значит, вне зависимости от типа буферизации (можно и 5 режим использовать) необходимо выполнить контроль введенных данных в событии Grid.BeforRowColChange()

Galyamov Rinat
Раньше работал только через переменные (в ините модифицирующей формы
заполнял control.value, по кнопке "применить" - все необходимые проверки, в.
т.ч. позволяющие пробегать по таблице источнику). А тут вот решил освоить
что-то новое :)
И это правильно! Даже если не получится использовать новый метод все-равно приобретете ценный опыт и новые знания.

Galyamov Rinat
> Как правило, в реальных приложениях напрямую с исходными таблицами
> работают крайне редко.
Дык я так понимаю что буферыы ввели как раз для того, чтобы не напрямую с
таблицами работать.
Не совсем. Цель буфера - это "развести" процесс внесения изменений (который может длится часами - пользователь вышел пообедать) и процесс сохранения внесенных изменений (который должен выполняться максимально быстро).

Т.е. пользователь вносит изменения в некоторую копию данных, а сами исходные данные при этом остаются не изменными до момента сохранения внесенных изменений.

Просто буферизация в FoxPro позволяет создать эту копию автоматически. У программиста нет необходимости создавать эту копию вручную. Ну, как Вы раньше создавали набор переменных.

Однако прямая правка таблиц, пусть даже и буферризированных имеет ряд проблем. В частности при использовании индексов Primary и Candidad. Поэтому для редактирования все-таки создают копию данных, но не через набор переменных, а через запрос (Select-SQL).

Этот запрос "оборачивают" в класс. В младших версиях FoxPro - параметризированное Local View, а начиная с VFP8 - класс CursorAdapter. При этом, при определенных настройках, изменения сделанные в Local View или CursorAdapter также автоматически будут "сбрасываться" в исходную таблицу.

По сути, тот же "буфер", но другими средствами.

Galyamov Rinat
> Другой вариант - это организовать контроль уникальности не через
> индекс, а через триггер на вставку. Вот триггер будет срабатывать только в
> момент сброса буфера. При определенных стандартах создания структуры базы
> данных можно написать универсальный (в рамках данной базы данных) триггер
> на контроль уникальности введенных данных.

Индекс - это все таки индекс. Он и быстрее и надежнее отработает чем тригер.
Вопрос спорный и не однозначный. Впрочем, не думаю, что имеет смысл затевать дискуссию на эту тему. Кое-что на эту тему можно почитать здесь

Контроль уникальности данных при помощи индекса

Плохой-советчикА все же индексы типа Primary и Candidad, я всегда считал, что должны заполняться автоматом и нечего юзеру самому там ползать.
Прописал в табличке в значении default value поля ссылку на Stored Procedures, где генерится уникальный индекс и забыл про это :D
Угу. Справочник контрагентов. Разумеется, названия контрагентов повторяться не должны. Разумеется, удаленные записи не должны включаться в контроль уникальности. Разумеется, легко написать Default Value, чтобы автоматом присвоить имя новому конрагенту.

С Primary-индексом, как правило, проблем нет. Разумеется, если используются суррогатные ключи. Проблемы начинаются с индексами Candidad. Тут довольно много "но" и "если"...