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

[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 больше нет

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

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

Цитата:

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

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

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

[Perc]

Цитата:

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

Не уверен.

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

Цитата:

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

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

[Raven Melancholic]

Цитата:

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

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

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

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

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

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

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