iBase.ru Forum

сабж

нет.

Так что это получается, если я делаю инсерт или апдейт в хранимой процедуре то это до фени ?

то это до фени ?

Кому? Выражайся проще, пожалуйста, я не понял ничего.

про транзакции вообще читал? www.ibase.ru/devinfo/ibtrans.htm

starttransaction и commit/rollback делает только клиент. в процедурах-триггерах это делать без надобности.

kdv писал(а):про транзакции вообще читал? www.ibase.ru/devinfo/ibtrans.htm

starttransaction и commit/rollback делает только клиент. в процедурах-триггерах это делать без надобности.

Дим. Иногда это требуется, и Fyracle это поддерживает. Но я согласег что использование commit в SP равнозначно попытке использования массивов.

Иногда это требуется

это тебе кажется

На самом деле, коммит в процедурах - это всего навсего сброс кеша и чистка сейвпойнтов. Т.е. наш commit retaining + пересоздание пустого сейвпойнт-стека процедуры в его виде на момент коммита/роллбека. Что технически сделать можно, хоть и накладно это будет. И я даже соглашусь, что иногда этого хочется. Но меня больше волнует семантика. Коммит нарушает логику обработки ошибок.

1) обработка ошибок в блоке

BEGIN
<блок 1>
COMMIT;
<блок 2>
END

в случае ошибки в блоке 2, отката первого блока не произойдет.

2) если сейвпойнты разрешены в PSQL

BEGIN
SAVEPOINT A;
COMMIT;
ROLLBACK TO SAVEPOINT A;
END

тут будет рантайм-ошибка, хотя компиляция пройдет.

Оба сценария провоцируют на сложный код, в котором будет масса ошибок. IMHO, разумеется.

давайте лучше сойдемся на том, что execute procedure - это оператор, а оператор должен быть атомарным (этот или любой другой). то есть, никаких commit/rollback внутри быть не должно по определению. И если мы с этим согласимся, то будем жить долго и счастливо.

kdv писал(а):

Иногда это требуется

это тебе кажется

Нет реальный опыт
На самом деле если БД проектируется правильно, то ни вкоем случае не стоит делать глупые подхода. Но в ситуации когда БД со структурой унаследованна от когото еще то увы от этого ни куда не дется.
Прямой случай с Сompiere и Fyracle.

dimitr писал(а):На самом деле, коммит в процедурах - это всего навсего сброс кеша и чистка сейвпойнтов. Т.е. наш commit retaining + пересоздание пустого сейвпойнт-стека процедуры в его виде на момент коммита/роллбека. Что технически сделать можно, хоть и накладно это будет. И я даже соглашусь, что иногда этого хочется. Но меня больше волнует семантика. Коммит нарушает логику обработки ошибок.

Вот это да, гдетолько народ такую траву берет :-/ ?

dimitr писал(а):1) обработка ошибок в блоке

BEGIN
<блок 1>
COMMIT;
<блок 2>
END

в случае ошибки в блоке 2, отката первого блока не произойдет.

Вполне мирно решается способом
BEGIN
<блок 1>
WHEN errors DO
<блок 2>
END

dimitr писал(а): 2) если сейвпойнты разрешены в PSQL

BEGIN
SAVEPOINT A;
COMMIT;
ROLLBACK TO SAVEPOINT A;
END

тут будет рантайм-ошибка, хотя компиляция пройдет.

Оба сценария провоцируют на сложный код, в котором будет масса ошибок. IMHO, разумеется.

Не это к практологу, человек выдумывает потом решет задачу и в итоге 8-0. Рельно в жызни то что написал Кузменко Д.

kdv писал(а):

Иногда это требуется

это тебе кажется

В oracle есть так называемая автономная транзакция (PRAGMA AUTONOMOUS_TRANSACTION), так вот в ее контексте можно писать независимо от того чем завершилась внешняя транзакция. Я таким образом логировал все ошибки пользователей в независимости от результатов внешней транзакции. Удобно. Не надо это делать в другой транзакции.

Лысый писал(а):

kdv писал(а):

Иногда это требуется

это тебе кажется

В oracle есть так называемая автономная транзакция (PRAGMA AUTONOMOUS_TRANSACTION), так вот в ее контексте можно писать независимо от того чем завершилась внешняя транзакция. Я таким образом логировал все ошибки пользователей в независимости от результатов внешней транзакции. Удобно. Не надо это делать в другой транзакции.

Возможно это уже флейм, то для логирования очень хорошо подходят external tables.

Все задачи можно решить немного другим способом

Лысый писал(а):В oracle есть так называемая автономная транзакция (PRAGMA AUTONOMOUS_TRANSACTION), так вот в ее контексте можно писать независимо от того чем завершилась внешняя транзакция. Я таким образом логировал все ошибки пользователей в независимости от результатов внешней транзакции. Удобно. Не надо это делать в другой транзакции.

Отправляемся читать про external tables. Что для целей тупого тотального логирования ещё удобней. Надоел этот лог - сбросил его в другое место или в корзину и подложил свежую болванку. Не надо о мусоре думать, о росте базы со скоростью звука и сопутствующих проблемах backup/restore. А стремление писать вне контекста транзакции в саму базу, а также коммитить или роллбачить часть изменений внутри оператора (вызов SP - это оператор SQL, как справедливо указал kdv) говорит либо о неумении пользоваться when и suspend, либо о проблемах в консерватории. Ссылки на чужие базы-процедуры не катят, ибо по сути есть - сделано проктологически, ни о чём не задумываясь, значит теперь настоятельнейше необходимо внедрить в сервер проктологию, обеспечивающую успешную работу проктологии, внедрённой в конкретную прикладную задачу. Если идти этим путём, то сервер очень быстро превратится в огромную выгребную яму, ибо имя проктологическим прикладухам и видам заключённой в них проктологии - легион.

>Merlin
Спорить на эту тему не буду (external tables для логов - руль) И предлагать ввести commit тоже не буду. Я просто ответил, что бывают случаи когда это могло бы пригодиться. Я пользовался тем что предоставлял Oracle, нет такого в FB - решу другим способом.

P.S. Кстати я не очень хорошо описал свое решение в предыдущем топике. На самом деле в лог попадали только уникальные ошибки. Я собирал их для русификации сообщений (именованные констрейнты + таблица с рус.сообщениями). Так что лог не был безразмерным.