Ошибка при вызове диалога

[Lucky13]

При выполнении данного кода

PHP код:

Args args = new Args();      
ttsbegin; 
new MenuFunction(MenuItemDisplayStr(PickingStat), MenuItemType :: Display).run(args);
ttscommit; 


Выдается ошибка:
Обнаружены непарные операции TTSBEGIN/TTSCOMMIT

В принципе вызов может быть любым, важно чтобы выдавалось диалоговое окно (наследник класса RunBase)

Подскажите почему нельзя вызвать диалог внутри транзакции?

[EVGL]

Просто нельзя, и все. Но если очень хочется, то максимум, что можно использовать, это DialogBox.

[Lucky13]

То что нельзя - это я уже понял. Хотелось бы знать почему. Это ошибка в классе RunBase или какая-то его уникальная особенность? Если второе, то для чего так сделано?
Например, в моем случае простым DialogBox не обойтись. Мне нужно вызвать таким образом стандартный класс, у которого есть диалог.

[MironovI]

Что интересно ошибка возникает не всегда! Эту тему я уже подымал где-то, тогда проверили - не падает, я удивился и оставил вопрос до выяснения, на самом деле самому очень интересно было бы узнать наконец в чем тут дело, если кто в курсе - UP и еще раз UP

[DenNik]

Цитата:

Изначально опубликовано Lucky13
То что нельзя - это я уже понял. Хотелось бы знать почему. Это ошибка в классе RunBase или какая-то его уникальная особенность?

Итересно... Один пользователь думает что ему набрать в диалоге, а другие его ждут...
Потом другой... Ждут остальные

Может всё таки собрать параметры до транзакции?

[George Nordic]

Цитата:

Изначально опубликовано Lucky13
То что нельзя - это я уже понял. Хотелось бы знать почему.

Вы еще спрашиваете?? Пользователь инициировал процесс, и в процессе ТРАНЗАКЦИИ (!!!) Вы вывешиваете юзеру диалог. А он, подлец, пошел покурить. А потом на обед. И у вас куча взаимных блокировок, все ждут, пока таблица освоболдиться

Цитата:

Изначально опубликовано MironovI
очень интересно было бы узнать наконец в чем тут дело, если кто в курсе - UP и еще раз UP[/B]

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

С Уважением,
Георгий

[EVGL]

Все правильно: никакая это не ошибка. RunBase ни при чем. Все формы в Аксапте выдают сообщение об ошибке, если вызываются внутри транзакции. Даже форма InventOnhandCheckReserve, которая на первый взгляд вызывается внутри транзакции, на самом деле активируется перед ней.

Так что запрашивайте все параметры до начала транзакции.

[Lucky13]

Логично. Видимо при вызове диалога закрываются все открытые транзакции, поэтому и возникает ошибка.

[MironovI]

Вот нарыл немного..

http://www.axforum.info/forums/showt...E0%EA%F6%E8%E8

И тут (последние 3-4 поста)

http://www.axforum.info/forums/showt...0&pagenumber=2

[MironovI]

Цитата:

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

Вы еще спрашиваете?? Пользователь инициировал процесс, и в процессе ТРАНЗАКЦИИ (!!!) Вы вывешиваете юзеру диалог. А он, подлец, пошел покурить. А потом на обед. И у вас куча взаимных блокировок, все ждут, пока таблица освоболдиться

По поводу "Вы еще спрашиваете?? " - допустим по ходу выполнения операции длящейся 30 часов возникает некая спорная ситуация, которая требует либо принятия решения либо отката ее целиком..

В 1С кстати (только не плюйтесь сразу ) - у любой формы, диалога есть таймаут - после его истечения форма закрывается и там обычно ставится ttsabbort; В Аксе я так понимаю такого нет.. да и не стоит пытаться сделать из хорошей системы 1С

[Wamr]

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

[MironovI]

Цитата:

Изначально опубликовано Wamr
Если после 30 часов возникает спорная ситуация и может принять решение только пользователь, то значит процедура спроектирована НЕВЕРНО и надо было подумать 30 часов назад и задать все вопросы юзеру ДО запуска.

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

[EVGL]

Цитата:

...это схоластика, даная необходимость может возникнуть и отрицать ее нельзя...

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

Я считаю, что дискуссии тут неуместны: примите как данность, наберитесь оптимизма и ищите обходные пути.

[MironovI]

Возвращаясь к этому посту http://www.axforum.info/forums/showt...0&pagenumber=2 - объясню в кратце - есть процедура синхронизации базы которая запускается в частности при импорте проекта - думаешь она идет в рамках транзакции?... Я тоже так думал.. и каково же было мое удивление.. оказывается при неудачном импорте изменений ты рискуешь и очень уронить базу, о последствиях и стоимости такой роскоши говорить излишне.. Так почему же такая важная операция идет без транзакции - да потому что в случае если при попытке построить новый уникальный индекс по таблице допустим требуется проверка уникальности данных и если они не уникальны - вылетает диалог с гридом неуникальных записей и тебе предлагают либо их удалить либо не создавать индекс.. Я свою базу поднимал недели две.. Ты конечно скажешь - а потому что ее неправильно написали - надо было сначала прооверить.. так вот - ошибки инициируются зачастую "недоступными инстанциями" аля - СУБД, COM, ActiveX..
МОе мнение - просто не хватило рук сделать нормально.. Ну я конечно понимаю что это реальность данная нам в ощущениях, но говорить что это правильно реализовано я бы не стал (тем более вываливание Ахапки я не считаю "реализацией", а скорее незаткнутой возможность сделать граблю в разработке)..

[Murlin]

А не мог бы кто нибудь дать ссылку на что-нибудь вроде Best Practice про все это. Большая просьба. Проблема в том что некоторая фирма оспаривает этот факт и требует денег за доработку изменения, а у нас из за этого блокировки висят, но правда там не диалог а Box, но сути наверное это не менят.
Причем требования у них сильно жоские там где этого по сути не требуется.
Самого уже это достало до жути, вообщем я то думал фирма "крутая", "супер-спецы", а я тут валенок сибирский.

[Murlin]

Цитата:

Сообщение от MironovI

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

Это тока в теории... А на практике работает совсем другое и не весит пол-системы, ушол человек чай пить и все, ждем когда он вернется все.

[S.Kuskov]

http://msdn.microsoft.com/en-us/library/aa609617.aspx

Цитата:

Do not use anything that requires a user interaction within a transaction (such as an action on a dialog box).

[user_ax]

Цитата:

Сообщение от Murlin

А не мог бы кто нибудь дать ссылку на что-нибудь вроде Best Practice про все это. Большая просьба. Проблема в том что некоторая фирма оспаривает этот факт и требует денег за доработку изменения, а у нас из за этого блокировки висят, но правда там не диалог а Box, но сути наверное это не менят.
Причем требования у них сильно жоские там где этого по сути не требуется.
Самого уже это достало до жути, вообщем я то думал фирма "крутая", "супер-спецы", а я тут валенок сибирский.

Насколько я понял, это даже не по циклу ВР, просто Аксапта не позволяет такого делать в принципе(архитектура приложения так устроена).

Цитата:

Сообщение от EVGL

Стандартная Axapta состоит из тысяч бизнес-процессов, однако она спроектирована так, что ни одного диалога в процессе транзакции в ней нет.

Цитата:

Сообщение от EVGL

примите как данность, наберитесь оптимизма и ищите обходные пути.

[Murlin]

Цитата:

Сообщение от S.Kuskov

http://msdn.microsoft.com/en-us/library/aa609617.aspx

Спасибо. Попробую если не получица я им на киргизский переведу.