Как найти вызов ttsBegin

[Logger]

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

[Perc]

Цитата:

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

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

В четверке нет такого логирования. Ну да ладно.. посмотрим в версии выше..

Несложной это какой? за созданием форм слежение из \xClassFactory\formRunClass сделано. Как бэ системой поддерживается..
А класс на что зацепится?

[Logger]

Цитата:

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

А класс на что зацепится?

Я в 4-ку перетаскивал из 2009-й
Еще добавил тут
\Classes\RunBase\new
\Classes\ClassFactory\createClass

помогает для Runbase а также для всего что по менюитем запускается. Конечно это не все классы охватывает но очень многое.
Также можно вот это применить
это одна из идей, которую я хочу пропихнуть в АХ 2012.

Ошибка с транзакциями!

[Perc]

В итоге xSession::xppCallStack() оказался совершенно бесполезным в поиске проблемы.
Самым простым и действенным получилось в onEventGoingIdle показать модальное окно после проверки ttsLevel. С третьей попытки пользователь таки прочитал сообщение и позвонил)

Проблема была на форме LedgerJournalTable. Ктото у нас на modified одного из полей сделал LedgerJournalTable_ds.write(). А во write на форме:

    ttsbegin;
    super();
    journalFormTable.datasourceWritePost();
    ttscommit;

Одно из обязательных полей таблицы было не заполнено. Поэтому в validateWrite() в super() аксапта поднимает какое то странное исключение с типом Warning. При этом код в validateWrite() доделывается, а все что было выше по стэку бросается, и транзакция еще не откатывается. В итоге имеем ttslevel=1. Далее пользователь умудряется все корректно заполнить, создать строки и разнести журнал. Потом аскапта совсем уж начинает сопротивляться, пользователь перезапускается - но журнала который он видел разнесенным, уже нет)
По мне write() в коде не выглядит каким то уж криминалом. А вот реакция системы с бросанием кода, но без отката транзакции - непонятно.. Предполагается что? Написать еще дополнительно проверку validateWite перед wite?

[Logger]

Цитата:

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

Написать еще дополнительно проверку validateWite перед wite?

Почему нет. Неплохой вариант. Ну еще try catch добавить.

[Perc]

Цитата:

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

Почему нет. Неплохой вариант. Ну еще try catch добавить.

Да все это выглядит как ересь. Затыкание багов(фитчей) ядра. По мне LedgerJournalTable_ds.write() уже должно включать весь сервис. Оно и включает, но как-то "не так". Или должна быть функция у DS которая аналог Ctrl+S.

Кстати вместо LedgerJournalTable_ds.write() я написал element.task(#taskSave) и все заработало аналогично Ctrl+S. Тогда сначала formRun запускает validateWrite, а потом только write. И тогда все срабатывает более менее адекватно.

Но по итого приходится разобраться зачем все это писали, и видимо вынесу ваще все что хотели сделать на update таблицы. И дело с концом..

Но в любом случае, работа исключений в validateWrite на форме - подкинула нежданчик..

[S.Kuskov]

Цитата:

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

Одно из обязательных полей таблицы было не заполнено. Поэтому в validateWrite() в super() аксапта поднимает какое то странное исключение с типом Warning.

Зачем вообще validateWrite бросает исключение? Разве он не должен просто вернуть false

[Perc]

Цитата:

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

Зачем вообще validateWrite бросает исключение? Разве он не должен просто вернуть false

ну так а что системе еще делать? validateWrite система сама вызвала в супере write. validateWrite вернул false - поле обязательное не заполнено. Проверял - поднимается
исключение типа info, выполнение обрывается, транзакция не откатывается системой. Но при этом если запихать вызов ds.write в try catch - то в catch ловится ttslevel уже ноль. Т.е. чтобы система сама откатила транзакцию достаточно поместить вызов в try. Это в 4-ке.
В 12-ке проверил - такой проблемы нет. Точно в таком же случае - транзакция абортируется в любом варианте.

Посмотрел стандартный sys-код в 4ке в этой же форме. MS проблему учитывали и писали с validateWrite:

void fieldModifiedBlockUserGroupId()
{
    if (! journalTable_ds.validateWrite())
        return;

    journalTable_ds.write();
    journalTable_ds.refresh();
}

этот метод они вызывают в modified поля формы.

[Владимир Максимов]

Цитата:

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

Зачем вообще validateWrite бросает исключение? Разве он не должен просто вернуть false

Речь идет не о коде, который может быть внутри validateWrite, а о полях со свойством mandatory = Yes.

Сам факт проверки заполнения этих полей происходит автоматически при вызове validateWrite(). Внутри super().Т.е. перехватить эту проверку - невозможно

Если надо перехватить проверку на mandatory, то это только "в лоб" до вызова validateWrite() или внутри до вызова super(). Т.е. тупо так

if (!common.Field1)
{
    warinig("Укажите значение поля");
}
else if (common.vaidateWrite())
{
    common.write();
}

[Владимир Максимов]

Цитата:

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

Одно из обязательных полей таблицы было не заполнено. Поэтому в validateWrite() в super() аксапта поднимает какое то странное исключение с типом Warning.

Это не исключение - это инфолог. Просто сообщение.

Цитата:

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

При этом код в validateWrite() доделывается

А вот это и странно. Разве там нет обработки того, что вернет super() ? Должно быть как-то так

boolean  validateWrite()
{
    boolean ret;

    ret = super(); // Внутри проверка полей со свойством mandatory = Yes

    if (ret)
    {
//  здесь пользовательские проверки 
    }

    return ret;
}

[Perc]

Цитата:

Это не исключение - это инфолог. Просто сообщение.

Вы как будто прочитали первых несколько сообщений в теме и решили ответить.. Прочитайте все. Уж на эти вопросы ответы несколько раз написаны..