Хранимая процедура для InterBase. Help.

← →
Step[B.M.] © (2003-06-28 09:29) [0]

Есть таблица с полями:

HACH - начислено оплат (руб.)
DATE_SK1 - дата начала скидки
DATE_SK2 - дата конца скидки
SUM_SK - скидка (руб.)
REAL_HACH - реально начиислено (руб.)

Нужна процедура которая для каждой записи в отдельности
выполнит логические действия, а именно:

1. если текущая дата НЕ попадает в диапазон дат
DATE_SK1 ... DATE_SK2 то:

REAL_HACH = HACH

2. если текущая дата попадает в диапазон дат
DATE_SK1 ... DATE_SK2 то:

REAL_HACH = HACH - SUM_SK

Большое Вам спасибо за любую оказанную помощь.

← →
XanderMan © (2003-06-28 11:05) [1]

for select DT.CODE, DT.DATE_SK1, DT.DATE_SK1
from DT
into :CODE, :D1, :D2
do begin
if ("TODAY" between :D1 and :D2) then
update DT set DT.REAL_HACH = DT.HACH-DT.SUM_SK where DT.CODE=:CODE;
else
update DT set DT.REAL_HACH = HACH where DT.CODE=:CODE;
end

← →
Step[B.M.] © (2003-06-28 13:08) [2]

Большое, Вам, СпасибО!!

← →
Zacho © (2003-06-29 23:50) [3]

А зачем процедура ? Как уже (к сожалению, в удаленной ветке) отвечал Johnmen, самое правильное решение - триггер BEFORE INSERT проимерно такого вида:
IF (NOW BETWEEN (NEW.DATE_SK1 AND NEW.DATE_SK2)) THEN
BEGIN
NEW.REAL_HACH=NEW.HACH-NEW.SUM_SK;
END ESLE
BEGIN
NEW.REAL_HACH=NEW.HACH;
END

← →
Step[B.M.] © (2003-07-04 08:44) [4]

Ок. А если надо сделать эти подщеты сразу одной транзакцией для всех записей, и делать это при вызове процедуры а не при вставке новой записи.

← →
Zacho © (2003-07-04 08:53) [5]

> Step[B.M.] © (04.07.03 08:44)

Все-таки, зачем процедурой ? Делается два триггера BEFORE INSERT и BEFORE UPDATE и в REAL_HACH всегда будут правильные данные, без всяких дополнительных телодвижений типа вызова процедуры.

← →
Step[B.M.] © (2003-07-04 08:59) [6]

Дело в том, что єтно надо делать РАЗ в МЕСЯЦ. :)

← →
Zacho © (2003-07-04 09:06) [7]

> Step[B.M.] © (04.07.03 08:59)

А, ну тогда действительно процедурой. Или без процедуры, двумя запросами.

Мда. Причем одной транзакцией.

А почему раз в месяц?
Это заказчик так придумал? Пусть объяснит, какой в этом смысл.
Я бы вообще вычисляемое поле сделал вместо всех этих процедур и триггеров. А насчет процедуры... один минус: многоверсионный механизм IB не очень любит такие подходы (типа в процедуре каждый раз данные перетряхивать непонятно зачем). Мусора много будет возникать. Особенно если таблица большая. Учти, что при таком действии количество записей в таблице реально всегда удваивается (в IB).
И вообще я здесь подозреваю в постановке задачи лажа имеется. Что значит начислять раз в месяц скидку на таких условиях? Скидка это что, атрибут платежа? Если это скидка, да еще от даты зависящая, то это атрибут другой сущности (клиента, договора) и храниться должна в виде процента в другой таблице.
А то странно как-то получается. Каждая строка в твоей таблице вроде - ОДИН платеж. И К КАЖДОМУ ТАКОМУ ПЛАТЕЖУ присвоены такие атирибуты, как ДИАПАЗОН ДАТ, когда ЭТОТ платеж имел скидку. Тебе не кажется все это СТРАННЫМ?

>Нужна процедура которая для каждой записи в отдельности
>выполнит логические действия, а именно:

Может, речь все же идет о двух таблицах?

Хранимая процедура для InterBase. Help. Найти похожие ветки