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

[Perc]

Проверка показала что исключение с типом Info на самом деле. Warning это в info.add подсовывается.

Цитата:

Беда с транзакцией-то откуда? почему ttscommit не выполняется в

Ну видимо это стандартное поведение write на датасорсе - если validateWrite вернул false, то прекратить дальнейшие действия.

Цитата:

Или у вас по непонятным причинам return false в validateWrite не выполняет как раз корректно, и вместо выхода из метода и перехода в следующий - идет передача управления пользовательскому интерфейсу (со все ещё открытой транзакцией)?

return как раз работает корректно. Что там можно сделать не корректно? return ret;
Невнятно ведет себя Акс4, не откатывая транзакцию. В акс2012, повторюсь, откатывает корректно.
Кажется и вам такое поведение видится некорректным - не можете в это поверить и ищете причину в наших собственных косяках))

[Logger]

А вы не могли бы попробовать провести эксперимент.

ttsBegin / ttsCommit
методы есть на самом табличном буфере(в частности при работе с времянками in memory лучше использовать их)

попробуйте в методе Write задействовать не обычный ttsbegin / commit а одноименные методы на буфере датасорса.

Есть подозрение что для работы датасорса формы ядро у вас использовало отдельное соединение к базе и при выбросе исключения откатило именно транзакцию открытую в этом соединении. А основную транзакцию в дефолтном соединении, которую вы открыли написав ttsBegin - не откатило.

Вот хотелось бы чтобы там был try catch и в catch проверить открыта ли транзакция на соединении связанном с буфером датасорса (я правда на все 100 не уверен что это отдельное соединение - вот и проверим). Как проверить уровень транзакции - Напрямую на табличном буфере методов нет. Но можно попробовать вызвать tableBuffer.ttsCommit() в цикле со счетчиком. Если уровень транзакции 0 то вызов должен по идее выругаться.

[Perc]

Цитата:

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

А вы не могли бы попробовать провести эксперимент...

Эмм.. все это странные версии.. ну пусть))
Замена ttsBegin на LedgerJournalTable.ttsbegin() не изменила в поведении ничего абсолютно. Так же вижу в отладчике уровень 1, также журнал создается разносится и при выходе из акс теряется.
try catch куда вставлять не понятно. Потому как я уже писал - стоит tts завернуть в try и тогда все корректно откатывается. Вот так работает нормально

try {
  ttsbegin;
  super();
  journalFormTable.datasourceWritePost();
  ttscommit;
}
catch {}

Единственно вопрос остался для меня открытым.
Нашей Акс4 сто лет в обед. В функциональности около журнала какбудто ничо не меняется столько же лет. Люди те же, с таким же стажем. Но жалобы характерные начались несколько месяцев назад.
Вот и думаю не может быть связано изменение поведения с админской частью? Сервера винды, SQL, терминалы - обновляют регулярно. не могло с этой стороны подвох прийти?
Есть еще у когото четверка живая? )

[Ace of Database]

Данные на формах редактируются в другом UserConnection. Когда вы смотрите в Аксапте активных пользоватей, то для тех, кто работает с формами, видно два разных SPID.
Метод write на датасурсе формы использует один UserConnection. А когда вы пишете в коде ttsbegin - ttscommit, то это применяется ко второму UserConnection. Поэтому когда внутри write выскакивает ошибка, то откатывается транзакция того UserConnection, который дла формы. А для того UserConnection'а, для которго написан в коде ttsbegin - для того транзакция не откатывается. И поэтому ttsLevel не сбрасывается.
А try - catch сбрасывает ttsLevel для того ttsbegin, который написан внутри кода для вашего UserConnection.
Этим самым и отличаюстя write на источнике данных формы от write на обычной табличной переменной. Ваш ttsbegin-ttscommit не действует на источник данных формы.
Если убрать try-catch, то выполнение кода внутри метода write источника данных сразу же прекращается, и не доходит до вызова ttscommit.

[Perc]

Цитата:

..Ваш ttsbegin-ttscommit не действует на источник данных формы..

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

У меня есть такой контрпример, что не все так однозначно..
есть два джоба - ttsbegin и ttsabort. есть тестовая форма с таблицей. Ни на таблице ни на форме нет ни одного метода - кода нет вообще. Ну а дальше вы уже догадались..
1. запускаю форму
2. запускаю джоб ttsbegin
3. в форме заполняю поля записи и закрываю ее. Снова открываю - запись на месте. Закрываю.
4. Запускаю джоб ttsAbort
5. Открываю форму. Записи введенной на шаге 3 больше нет

Как это объясняет теория об отдельной жизни форм?

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

Цитата:

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

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

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

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

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

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

[Pandasama]

Цитата:

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

Ну так и обязательные поля исключения вроде бы не кидают, а просто в super() метода validateWrite возвращают false?

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

Цитата:

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

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

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

Цитата:

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

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

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

boolean  validateWrite()
{
    boolean ret;

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

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

    return ret;
}

[Perc]

Цитата:

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

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

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

Изначально это ответ был вообще не Вам А во всех последующих сообщениях Вы упорно пишете об исключении типа Warning. Но это не так

Да, тут странно, что прерывание FormDataSource.Write() не обнуляет ttslevel(). Но сильно подозреваю, что проблема в каком-то дополнительном коде. И, скорее всего, где-то в ValidateWrite(). Вот сомневаюсь, что это ошибка на уровне ядра.

Тут бы простой тест сделать, раз у Вас уже есть голая форма и голая таблица. Добавьте в таблицу поле с mandatory = Yes, перекройте на форме DataSource.write(), окружив super() транзакцией и проверьте, обнулится ttslevel() или нет?

[Perc]

Цитата:

Изначально это ответ был вообще не Вам

Ну тема моя поэтому я тоже участвую)

Цитата:

А во всех последующих сообщениях Вы упорно пишете об исключении типа Warning. Но это не так

Именно исключение - ловится в catch

Еще вам за напраслину минус. Я про Warning один раз писал. Проверьте. Потом везде info.
А вверху второй страницы я уточнил конкретно:
Проверка показала что исключение с типом Info на самом деле. Warning это в info.add подсовывается.

Цитата:

Тут бы простой тест сделать..

Конечно же. Когда появились версии, я многое проверил на простом тесте. И этот тест сразу.
Но еще раз повторяю для вас. Проблемы нет если сохраняете стандартно - Ctrl+S. В этом случае_DS.validateWrite система сама запускает до _DS.write(). Проблема тогда когда _DS.write() вызывается из кода. Добавляю на форму кнопку с кликедом в котором _DS.wite(). Жмем и проблема проявляется.

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

Цитата:

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

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

Не уверен. Но, вроде бы, в dax4 генерацию новых значений номерных серий делали в отельном соединении. Может, проблема связана с номерными сериями?

[Perc]

Цитата:

Сообщение от Владимир Максимов

Не уверен.

В чем не уверены? Я свой пример привел.
С вашей стороны есть проверяемый пример подтверждающий обратное? или что имели ввиду

Цитата:

Но, вроде бы, в dax4 генерацию новых значений номерных серий делали в отельном соединении. Может, проблема связана с номерными сериями?

Ну мы же уже попробовали "голую" форму с "голой" таблицей. Какие там номерные серии? Их нет.. ну разве что recid.. Да он то тут причем?

[Raven Melancholic]

Цитата:

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

В чем не уверены?

Я так думаю, что Владимир Максимов не уверен в теории, высказанной Ace of Database об отдельном соединении пр работе датасорса формы.

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

Вот то что Аксапта при сохранении данных датасорса формы вообще не открывает явную транзакцию в MS SQL еще могу предположить (опять же только предположить) - работает неявная транзакция MS SQL. Понятно, что обязательность поля контролируется не на уровне MS SQL, а движком и сам движок выдает исключение, сам же его и перехватывает.

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

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

[Raven Melancholic]

Еще, насколько помню, порядок вызова тригерных методов курсора в форме (имею ввиду update, validateWrite таблицы, write, validateWrite датасорса формы) какой-то не очень понятный сразу (по крайней мере для меня, может быть логика какая-то есть).

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