Транзакция и EXECUTE STATEMENT

← →
PEAKTOP © (2007-04-11 11:05) [0]

Вопрос по контексту транзакции оператора EXECUTE STATEMENT.
1)Есть хранимая процедура, которая вызывается на триггере проведения документа.
2) Хранимая процедура формирует SQL-скрипт и выполняет его через EXECUTE STATEMENT. Скрипт представляет собой конструкцию вида EXECUTE BLOCK RETURNS( A_SQL VARCHAR(16000)) AS ....
3) Далее выполняется цикл выборки поля A_SQL из сформированного скрипта
FOR EXECUTE STATEMENT :P_SQL_STMT INTO :P_SQL DO
BEGIN
INSERT INTO TABLE_LOG(J_ID, RUNNED_SQL)VALUES(10000000, :P_SQL);
EXECUTE STATEMENT :P_SQL;
END
Оператор Insert в данном цикле протоколирует выполненные SQL-команды.

Теперь, собственно, вопрос: Записи в логе после проведения документа не видны до переподключения к базе данных. Хотя данные, появившиеся в результате выполнения в цикле очередного фетченного P_SQL (в основном INSERT-скрипты), в таблицах появляются.

Получается, что если в EXECUTE STATEMENT запихать EXECUTE BLOCK, то контекст транзакции этого оператора изолирован от контекста транзакции вызвавшей его хранимой процедуры ?

← →
Johnmen © (2007-04-11 11:45) [1]

Ту уже так давно на форуме, что мог бы привыкнуть соблюдать правила. В частности, указывать тип СУБД. И не важно, что кто-то догадается.

← →
PEAKTOP © (2007-04-11 12:25) [2]

> Johnmen © (11.04.07 11:45) [1]
Прошу прощения, забыл форму заполнить до конца.
Firebird v2.0

← →
Johnmen © (2007-04-11 20:26) [3]

> PEAKTOP © (11.04.07 11:05)

Нет. Все эти действия выполняются в одной транзакции.

>Записи в логе после проведения документа не видны до переподключения к
>базе данных.

Просто подтверди тр-ю, котораю д.б. типа ReadCommitted.

← →
PEAKTOP © (2007-04-12 10:32) [4]

> Просто подтверди тр-ю, котораю д.б. типа ReadCommitted.
Механизм работы такой:
1) Есть trJournal:TIBTransaction.
trJournal.Params.Add("isc_tpb_read");
trJournal.Params.Add("isc_tpb_rec_version");
trJournal.Params.Add("isc_tpb_nowait");
2) Есть qrJournal :TIBQuery; qrJournal.Transaction := trJournal, обеспечивающий интерфейс пользователя (отображение документов в гриде).
3) Есть штук пять TIBQuery, связанные с qrJournal по Мастер-Деталь, для отображение движений по регистрам (т.е. записей из таблиц, вставка данных в которые осуществляется механизмом в посте №0). Транзакция у всех trJournal. Открываются/закрываются наборы данных в событиях AfterOpen/BeforeClose компонента qrJournal.
4) Есть функция function ExecSQL(const SQL:string):Boolean; которая , создает компоненты транзакцию и TIBSQL, а затем выполняет через них SQL-скрипт. У транзакции этой функции параметры
trTemp.Params.Add("isc_tpb_read_commited");
trTemp.Params.Add("isc_tpb_write");
trTemp.Params.Add("isc_tpb_no_rec_version");
trTemp.Params.Add("isc_tpb_wait");
После выполнения скрипта функция делает trTemp.Commit;

Далее поведение программы:
1) Пользователь выполняет команду "Провести" документ ExecSQL("UPDATE MY_TABLE TB SET TB.FLAG_COMMIT = 1 WHERE TB.ID = 100000000").
2) Срабатывает триггер на AFTER UPDATE, который вызывает процедуру, описанную в посте 0. Процедура вставляет записи в таблицы движения по регистрам и в таблицу логов.
3) Срабатывает триггер на AFTER INSERT OR UPDATE OR DELETE и делает POST_EVENT.
4) В клиентском приложении TIBEvents ловит событие и делает
trJournal.Roolback;
qrJournal.Open;

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

← →
Johnmen © (2007-04-12 10:39) [5]

1.
"read_committed"
"rec_version"
"nowait"
2.
Не надо использовать Евентер! Это бяка :)
Опять же евент придёт только после подтверждения тр-ии.

← →
PEAKTOP © (2007-04-12 11:08) [6]

Вопрос снимается - ошибка была как всегда в 17-й строке :))) У qrJournalSQLLog забыл выставить свойство Transaction и оно юзало Транзакцию компонента TIBDataBase.

> Johnmen © (12.04.07 10:39) [5]
> "read_committed"
> "rec_version"
> "nowait"

Кстати - да, спасибо.

> 2.
> Не надо использовать Евентер! Это бяка :)

Почему ? Работает же.
Я до того, как в базы влез, занимался программированием ПО для удаленного администрирования LAN. Поэтому механизм асинхронного управления данными (в одном потоке отправляем данные серверу, в другом читаем ответ) для меня "родной". Оттого и привык к IBEvents. Да и люди его рекомендуют http://ibase.ru/devinfo/clientrefresh.htm.

Если эвентер бяка, то подкажи другой метод "живого" набора данных.

← →
Sergey13 © (2007-04-12 11:13) [7]

> подкажи другой метод "живого" набора данных.

Это миф. При том достаточно вредный и бесполезный по большей части.

← →
PEAKTOP © (2007-04-12 11:39) [8]

> Это миф. При том достаточно вредный и бесполезный по большей части.

Почему бесполезный, если надо видеть что какой-то дятел (не путать с Yaffil) в твоей сети уже провел этот документ ?

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

← →
Sergey13 © (2007-04-12 11:52) [9]

> [8] PEAKTOP © (12.04.07 11:39)

Потому, что "по состоянию на "прямо-сейчас"" - это тоже миф? 8-)

← →
Johnmen © (2007-04-12 11:54) [10]

> PEAKTOP © (12.04.07 11:39) [8]
> Почему вредный, если бухгалтер ....

Так он хочет только "видеть", т.е. заниматься исключительно мониторингом, или всё же еще желает что-то там редактировать и т.п.?
Если мы сейчас начнём дискутировать на эту тему, то утонем в постах. Причём никто друг друга не будет слушать и понимать.
Поэтому надо один раз чётко понять, для чего КОНКРЕТНО предназначено приложение - для мониторинга или для обслуживания, и принять решение по поводу Евентера.

> Если мы сейчас начнём дискутировать на эту тему, то утонем в постах.

Присоединяюсь, холивара не будет. :)))

Автоматизируемая задача - ERP-система, имеющая интегрированный CAD для построения изделий, входящих в заказ (вариант расходной накладной). И если кто-то провел заказ, а другой в это время редактирует в CAD-е изделие из этого заказа, то по логике бизнес-процессов заказчика редактирующему должна вылететь большая птица обломинго. Реализовать это как-то по другому, кроме как на IBEvents не додумался.

>Реализовать это как-то по другому..
стоит почитать про блокирование записей и подходы к нему.

> стоит почитать про блокирование записей и подходы к нему

Была такая мысля, но к сожалению в данной ситуации это не применимо . :((
В других местах пользую не стесняясь.

← →
Jan1 (2007-04-12 14:25) [14]

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

У него на клавиатуре клавиша F5 специально выковырена? Или руки у него короткие чтобы до нее дотянуться?

← →
Jan1 (2007-04-12 14:30) [15]

> Реализовать это как-то по другому, кроме как на IBEvents
> не додумался.

почему нельзя сделать версионность, почти как в ФБ. или Блокировки на уровне транзакций как говорят в [12]?

Транзакция и EXECUTE STATEMENT Найти похожие ветки