Почему-то вылетатет транзакция

[bolt]

В процессе открытия некой вспомогательной формы и её обработки почему-то происходит закрытие транзакции, хотя ни ttscommit ни ttsabort нет. Соответственно выдается ошибка. Как это обойти? Транзакцию прерывать специально нехочется очень-очень.

[mazzy]

закрытие - это нормальный commit?
тогда странно. Барабашки нет - ищите ttscommit.

если под закрытием вы подразумеваете rollback, то rollback может автоматически делать возникшее исключение. Т.е. где то есть либо throw, либо нечто, что возбуждает исключение. Если нет обработчиков, то Аксапта сама откатывает транзакцию.

[dirigente]

В коде:
....

PHP код:

ttsbegin;
    SomeFunction();
ttscommit;
....
boolean SomeFunction()
{
     //Создание FormRun, содержащей CommandButton OK. 
     //Далее init(), run(), wait();
} 


В результате появляется на экране форма, при нажатии на OK вылетает ошибка контроля транзакций TTS - непарные транзакции.
При закрытии окна (используем кнопку окна x) - все нормально.
Таким образом, где-то в районе closeOK()/closeCancel() и возникает это самое "что-то", что вызывает исключение. Т.е. Аксапта "забывает" ttsbegin, видимо ...
Эксперимент повторяем с устойчивым результатом.

Как это можно обойти?

[Garic]

Ничего удивительного. Такого ни в коем случае нельзя делать.
Представте себе ситуацию - открывается транзакция, потом открывается форма. Сотрудник уходит на обед, а транзакция висит...

[dirigente]

Идея понятна. Однако если внимательно прочитать мое пояснение, то станет ясно, что следуя Вашим рассуждениям, Аксапта не должна давать открывать форму, но это не так.
Решение уже найдено - мы просто меняем CommandButton на Button и в
Click() обрабатываем (в зависимости от кнопки) результат и закрываем форму close(), а не closeOK() или closeCancel(), которые вызываются в случае с CommandButton автоматически, - так работает.
А транзакции, IMHO, на то и есть чтобы обеспечивать целостность данных вне зависимости от причин прерывания.
Вас пугает возможность приостановить транзакцию на длительное время?
Но видите ли, все зависит от контекста. В нашем случае ЭТО НЕ КРИТИЧНО.
Вопрос-контраргумент: а как быть если в середине обычной (т.е. в Вашем понимании - программно непрерываемой) транзакции, время исполнения которой составляет доли секунды, происходит сбой?
Все же я склонен считать, что здесь какие-то другие причины или ошибка.

Спасибо.

[Vadik]

Цитата:

Изначально опубликовано dirigente
Вас пугает возможность приостановить транзакцию на длительное время?

думается, Garic-а пугает возможность парализовать на длительное время работу БД (и предприятия)

Цитата:

Изначально опубликовано dirigente
Вопрос-контраргумент: а как быть если в середине обычной (т.е. в Вашем понимании - программно непрерываемой) транзакции, время исполнения которой составляет доли секунды, происходит сбой?

А никак - она будет откачена сервером. У него логика простая (железная), его дело не допустить нарушений целостности, он это и делает в меру возможностей, дискутировать с ним бесполезно

гадать о причинах такого поведения, не видя кода SomeFunction можно долго и безрезультатно. Внутри нее никаких исключений/ошибок не выбрасывается?

[dirigente]

По поводу остановки базы/предприятия я уже написал - в данном конкретном случае этого по логике не произойдет....

Я просто пытаюсь сказать, что,возможно, есть такая особенность: если внутри ttsbegin - ttscommit вызывается функция, в которой создается FormRun с минимум одной CommandButton (OK) И ВСЁ. Инициализируется и запускается, то при нажатии на ОК возникает ошибка непарных транзакций. Никаких исключений внутри самой функции не возникает и не выбрасывается. Нашу конкретную проблему мы решили, как я уже говорил, тем не менее сама проблема остается. Можно обойтись и без вызова функции,например:

PHP код:

static void Job3(Args _args)
{
    Args args=new Args();
    FormRun dialog;
    ttsbegin;
    args.name(formstr(TestForm));
    dialog = ClassFactory.formRunClass(args);
    dialog.init();
    dialog.run();
    dialog.wait();
    ttscommit;
} 


При нажатии на ОК - ошибка.
Форма TestForm - обычная форма с CommandButton OK.
Все параметры - по-умолчанию.

Ну как?

[Vadik]

Цитата:

Изначально опубликовано dirigente
Ну как?

аналогично
а если бы и работало, все равно не повод вызывать формы и диалоги внутри транзакции

[Garic]

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

[dirigente]

2Garic:
Вы понятия не имеете, уважаемый, что за задача стоит, я об этом и не говорил и не спрашивал, стоит ли мне еще раз подумать.
Если бы мы делали задачу "с нуля", то такого бы не допустили, однако ...
Если Вы видите здесь грубую ошибку - так скажите что же это за ошибка, а если не знаете - зачем ... говорить?
Если уж говорить о методике модификации функционала Аксапты, то об этом можно спорить долго и безрезультатно.
В данном случае альтернативой является изменения функционирования основных классов.

[raz]

А почему не сделать транзакцию внутри формы?

[dirigente]

Господа, я вас просто-таки очень прошу!
Выше приведен пример (Job с описанием).
Я не спрашиваю как обойти ошибку - будь то методологически или программно - МЫ УЖЕ ЕЕ ОБОШЛИ.
Я ПРАВДА НЕ ВИЖУ здесь ошибки программирования, как утверждает уважаемый Garic!

Просто объясните если знаете: ПОЧЕМУ ВОЗНИКАЕТ ОШИБКА? Почему ее нет в случае использования обычной кнопки (НЕ CommandButton) и метода close() по событию click().

Спасибо.

[Антон Солдатов]

Цитата:

Изначально опубликовано dirigente
Я ПРАВДА НЕ ВИЖУ здесь ошибки программирования, как утверждает уважаемый Garic!

Во время транзакции блокируются не только записи в таблицах, но и экстенты сегментов отката. Это такие логические группы блоков данных в механизме журналирования и отката изменений в Oracle. Если Ваша длительная транзакция и еще одна любая транзакция аксапты с записью большого объема данных будут привязаны к одному сегменту отката(такое вполне возможно), то может возникнуть ошибочная ситуация, в результате которой, транзакция с большим кол-вом записываемых данных будет отменена.
Вероятность того, что эта ситуация возникнет, растет с кол-вом таких ляпов в программировании, частотой использования Вашей формы и т.д.
Даже если ситуация, описанная выше, не произойдет - благодаря вашему стилю смешивать presentation и persistent логику, существенно возрастет ресурсопотребление СУБД. Если экстент занят вашей транзакцией долгое время, вместо переиспользования существующих, серверу понадобится производить операции создания новых экстентов, а в последствии их удаления.

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

Цитата:

Изначально опубликовано dirigente

Просто объясните если знаете: ПОЧЕМУ ВОЗНИКАЕТ ОШИБКА?

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

[ta_and]

Полностью согласен с Антоном Солдатовым.

Недопустимо смешивать транзакционную с презентационной логикой для пользователя.
Все предварительные настройки и запросы пользователю должны быть сделаны ДО начала транзакции.

[dirigente]

Что ж, спасибо.
Я полностью согласен и понимаю, что так делать неправильно.
НО для нашей задачи этот вариант приемлем - детали выдавать долго и неинтересно.
И еще несколько замечаний, если позволите.
1. Я полностью согласен, что использование каких-бы то ни было прерываний между ttsbegin/ttscommit - плохая логика, однако еще раз хочу подчеркнуть: не стоит давать оценку стиля программирования, понимания задачи, если вы не знаете задачу и не видели код, все остальное - домыслы.

Цитата:

Изначально опубликовано Антоном Солдатовым

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

Еще раз спасибо - это очевидные вещи.
А про автоматический Commit по OK - вот это действительно интересная мысль. Или это установленный факт?

P.S. Думаю не стоит давать оценки тому, о чем вы не имеете представления - это на тему причин такого решения и прочее.
P.P.S. На тему стиля - те кто присутствовал на встрече с клиентами MBS в декабре минувшего года - стали очевидцами ситуации, когда некий господит обвинил MBS в том, что самый известный партнер, в чьем профессионализме не приходится сомневаться, выкатил стоимость перехода с версии 2.5. на 3.0. = стоимости первоначального внедрения. При этом вскользь вышеупомянутый господин сообщил, что многое из того, что только в планах MBS они уже сами (т.е. партнер) реализовали. И для этого господина и Co такая цена стала абсолютным откровением .... но это уже была другая Аксапта.

[Антон Солдатов]

Цитата:

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

Мое(и не только мое) скромное мнение, проверенное не единожды: любая задача не оправдывает подобных действий.

Цитата:

Изначально опубликовано dirigente

А про автоматический Commit по OK - вот это действительно интересная мысль. Или это установленный факт?

это логически обоснованная догадка. нужно проверять...

[dirigente]

2Антон Солдатов

ОК. Спасибо большое.

[Wamr]

Неоднакратно проверенный факт - НЕЛЬЗЯ открывать формы внутри транзакции. Аксапта выдаёт ту самую ошибку о нарушении парности - воспринимайте это сообщение как запрет на такие фокусы.

[_A_]

ttsbegin;
...
if(box::yesno("", DialogButton::Yes, "", "") == DialogButton::No)
throw error("");

...
ttscommit;


Сие аксапта проглатывает запросто,
однако... вах - в сегменте отката у нас будет валяться всякий хлам пока не натиснем кнопочку Yes или No на Dialoge.

значит таки акса позволяет висеть транзакциям... и чудненько завершит или откатит по нажатию той или иной кнопки.

[garu]

Аксиома - НИКАКИХ ДИАЛОГОВ С ПОЛЬЗОВАТЕЛЕМ ВНУТРИ ТРАНЗАКЦИИ!!!!!!!