Ну, давай по шагам
k_sv
Есть таблица и на ее базе - обновляемое представление.
1. Устанавливаю 5-ю буферизацию и на таблицу и на представление.
2. Добаляю запись в представление.
3. Tableupdate представления.
Вот в этот момент в буфере представления ничего нет . Новая запись была успешно сброшена из буфера. Другой вопрос, куда она попала? А попала она в другой буфер. Исходной таблицы. Хотя в саму таблицу пока не попала.

k_sv4. Удаляю добавленную запись.
Я так понимаю, что удаляешь из представления. Тогда важное уточнение. Ты удалешь уже не новую запись, а реально существующую запись с точки зрения представления. Ведь до команды удаления произошел сброс буфера. Т.е. представление уже не знает, что эта запись "новая". Оно вполне справеливо считает, что это некая существующая запись.

k_sv5. Tableupdate представления.
Т.е. происходит обычная модификация ранее существовавшей записи. На всякий случай напоминаю, что "удаление" в данном случае, это всего-лишь установка метки, т.е. некая модификация записи.

В результате, метка об удалении попадает в буфер исходной таблицы.

k_sv6. Tableupdate таблицы.
Перед этой командой имеем в буфере исходной таблицы новую запись, помеченную как удаленная.

k_svПосле всех этих действий добавленная (и затем удаленная запись) остается в таблице.
Правильно. Из буфера исходной таблицы ВСЕ модификации попадают в саму исходную таблицу. Даже такие "фиктивные" как удаление только что созданной записи.

k_svЕсли же делать между (3) и (4) Tableupdate таблицы, то все нормально.
Не понял, что именно "нормально"? В описанном сценарии ничего не изменится. В итоговую таблицу все-равно попадет новая удаленная запись.

Если необходимо, чтобы новая запись, которая тут же была удалена не попала в исходную таблицу, то удаление надо делать непосредственно в представлении ДО сброса буфера. Т.е. исключить пункт (3).

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

k_svНо начнем с начала.
Штирлиц: Вот с этого и надо было начинать!
Мюллер: Мне лучше знать, с чего начинать!



k_svБуферизацию таблицы и представления я делаю для того, чтобы получить 2 соответствующих селекта (на начальные данные и измененные). И в зависимости от этих результатов и данных другой таблицы разрешаю или запрещаю сохранение.
Не совсем ясно, почему нужны именно запросы и почему именно в буфере, а не в триггере. Может, опишещь задачу более подробно?

k_svНо насколько я понимаю, селект отбирает данные из таблицы (или представления), а не из буфера.
Да. Хотя в VFP9 появилась возможность делать запрос с учетом буфера.

k_svПолучается такая картина:
1. либо мне надо вытаскивать данные из буфера представления во временную таблицу (сомневаюсь, что это возможно);
Можно. Только не запросом, а в цикле (прямой перебор записей), используя функции

GetNextModified()
GetFldState()

k_sv2. либо опять же обновлять представление (выполять свой 3-ий пункт!!!), делать селект.
А как это поможет? Ведь сброс произойдет не в исходную таблицу, а в ее буфер. Т.е. Select-SQL опять ничего не увидит. В исходную таблицу ведь ничего еще не попало.

k_svИ что же мне делать?
Возможно я не понимаю задачу. Слишком мало информации. Но почему нельзя перенести всю эту проверку в триггер на INSERT и UPDATE таблицы?

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

k_svПока Игорь Королев не делал вечерний обход форума, спешу задать вопрос.
Опоздала, обход уже был совершен

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

В общем случае.

Если ввод осуществляется интерактивно (самим пользователем), то RULE использовать нельзя. Эффект его использования сопоставим с запретом выхода из TextBox.Valid(). Слишком жесткое ограничение. Триггер в этом случае - более разумное решение.

Если ввод осуществялется программно (речь идет о служебном поле, недоступном для прямого редактирования пользователем), то тут возможны варианты.

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

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