Igor Korolyov

PaulWist
Надо использовать правило поля

В данном случае правило поля не годится, т.к. речь идёт о правиле "сумма по полю amount для всех записей с определённым code должна быть больше нуля". Правило поля применяют для проверок корректности данных только в одном поле одной записи, правило записи - для проверки коррекности затрагивающей разные поля одной записи, а когда речь заходит о группе записей, или записях из другой таблицы (классический пример referential integrity) то это уже работа для триггера.

Посмотри ещё раз условие задачи:

ZenTigra

Есть две таблицы
table1 и table2

Структура table1
key - поле ключа
suma - сумма по полям table2

Структура table2
key - поле ключа для связи с table1
suma2 – любые цифры

Необходимо чтобы при изменении поля suma2 в table2 происходило автоматическое изменения значения поля suma в table1

Вот на подобии, этого.
table1
key suma
a1 100
a2 200

table2
key suma2
a1 50
a1 20
a1 30
a2 200

И вопрос:

ZenTigra
Еще одно проблема.
Поле suma - не должно быть нулевым, и если пользователь набрал a1 -120 ...

речь идёт о "шапке/регистре, например остатков" table1.suma, а не деталях table2.suma2 (какие значения д.б в table2.suma2 не определено), поэтому вполне правильно использовать правило поля для поля table1.suma.

Как то не хватило сил прочесть все сообщения, и может кто то уже говорил.

Я полагаю, табле1 не нужна. Она просто всегда получается выборкой.
Задача достаточно обычная, и не встречал что бы решали ее по другому.
Не, бывают конечно регистры... но это особые решения, для ускорения. А тут гроши.

leonid

pasha_usue
Функционал почти оракловский

Ну, все-таки не дотягивает. Хинтов нет, статистики нет.

Ну, продукт бесплатный, и у него есть немало фишек, которые в Оракле можно сделать, но не так удобно. И продукт развивается. А статистику (я не админил PG, но разговоры слушаю) вроде как собирает. Хотя (не исключаю) я в это понятие вкладываю несколько другое. Ну даже ЕСЛИ ее действительно нет - то, думаю, сделают. Не, мне PG нравится, хороший продукт, хорошие возможности. Ну и подключай немало ЯП (Java, Pyton, C). Наследуемые таблицы и прочие фишки... Паша Кручинин тоже за него горой.

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

Вообще, ТС надо обозвать свою таблицу регистром, и всем полегчает.

lulgu
Фоксовские триггеры для практической работы непригодны, все это бла-бла-бла уже два десятка лет..
Такие задачи в фоксе практики обычно решают кто как может, так проще.
А теоретики козыряют наборами SQL-языков, как своими.

ЗЫ. В принципе, можно создать универсальный класс _Trigger, куда с умом вынести коды из RI
Только смысла в этом немного, это возня на любителя.

Сегодня я соглашусь почти под каждым словом. Кроме того, что и класса не надо создавать в СУБД FoxPro.

Не создавай, никто не заставляет.