Не надо сканировать ту таблицу, модификации в которой и выполняются. Лучше сделайте более простой триггер


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

Но, раз данные еще не записаны, то что же вы планируете считывать через запросы? Ведь запрос - это обращение напрямую к таблице-источнику. А в ней внесенных изменений пока еще нет. Они есть только в текущей рабочей области.

Вот вам подзапрос по tab2 "фигню" и возвращает. Точнее, он возвращает данные по состоянию ДО модификации.

А прямое чтение поля таблицы в текущей рабочей области как раз и вернет значение ПОСЛЕ модификации.

Триггера FoxPro обрабатывают по одной записи за раз. Групповая обработка записей невозможна. Поэтому внутри тела триггера всегда находимся на одной записи таблицы, вызвавшей срабатывание триггера.

LUCIAN

Вообще-то, конечно, в данном случае можно обойтись и без этого анализа. Написав примерно так


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

Анализ производится через оператор CASE по той причине, что данный оператор прерывает свое выполнение в тот момент, когда очередной CASE примет значение .T. Это значит, что если перешли на очередной CASE, то все предыдущие вернули .F.

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

Следующая проверка выглядит так


Раз мы попали на эту проверку, то данную функцию вызвал либо триггер на вставку, либо триггер на модификацию.

Триггер на вставку может сработать по двум причинам:

1. При физическом создании новой записи
2. По команде RECALL при снятии метки на удаление

Если дали команду Recall, то, очевидно, что OldVal("Deleted()") вернет .T. Ведь до модификации записи эта запись была помечена как удаленная. Однако напомню, что в данный момент запись НЕ помечена как удаленная. Это уже проверили на предыдущем этапе.

Если же это физическое создание новой записи, то OldVal() по любому выражению вернет NULL.

Вот и получается, что это условие читается примерно так:

До модификации был установлен признак удаленной записи, который сейчас сняли ИЛИ это новая запись

Это условие может вернуть .F. только и исключительно тогда, когда ДО модификации Deleted()=.F. Т.е. запись существовала и это не есть удаление, поскольку этот факт был проверен еще на первом CASE. Значит, Otherwise - это только и исключительно модификация.

=============================

Кроме того, не следует внутри тела триггера обращаться по имени таблицы явно. Вот эта самая конструкция


потенциально опасна. Может привести к не предсказуемым последствиям.

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

Во-вторых, очевидно, что имя таблицы, в общем случае, может не совпадать с алиасом, используемым в той рабочей области, где таблица была открыта. А это значит, что команда


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

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


Также следует озаботится "уборкой мусора". Точнее, возвращение в то состояние при выходе из триггера, которое было на момент входа в триггер. Закрыть все таблицы, открытые в теле триггера и вернуться в ту рабочую область, в которой были при входе в триггер.

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