1с в данной транзакции уже происходили ошибки
Подобная ошибка может произойти при обработки ситуации «Попытка-Исключение». Например, при создании записи «Объект_1» формируется исключительная ситуация, а сама ошибка появляется в «Ссылка_2.Наименование». То есть происходит запрос базы данных объектной модели.
В «Попытке-Исключение» начинается обработка операции, которая также должна быть выполнена в транзакции, которая, в свою очередь, может быть явной или неявной (создается в момент записи объекта).
1С: Предприятие 8.3 не поддерживает транзакций вложенного типа. Однако допускается создание вложенной конструкции сразу нескольких транзакций. Из-за наличия явной и неявной транзакции может возникнуть ошибка. То есть программа запрещает транзакцию 1-го уровня на более низших уровнях.
Есть ли смысл исправлять ошибки транзакции, которые уже происходили
При работе с 1С 8.3 не стоит оставлять подобные вещи без внимания. Прежде всего, другой пользователь также может столкнуться с ней, но не поймет причин её возникновения. Если не выполнить отладку системы, то в дальнейшем могут возникнуть дополнительные проблемы. Так как оповещение «В данной транзакции уже происходили ошибки» появляется при первом обращении, то в журнале регистрации данная строка обязательно зафиксируется, но, опять же, без подробного пояснения. Хоть ошибка и располагается на нижнем уровне кода, она нарушит необходимую иерархию. Это приведет к сбою других функций и только еще больше запутает администратора.
Устраняем ошибку транзакции в 1С Предприятие версии 8.3
В первую очередь стоит очистить кэш базы данных. Сделать это можно вручную. Для этого:
Также можно выполнить удаление другим способом:
После того, как файл преобразуется, его можно запустить и весь пользовательский кэш удалится автоматически. Пробуем снова запустить программу и выполнить операцию. Если не помогло, то лучше всего обратиться к администратору. Также нужно помнить про основные особенности написания кода с использованием транзакций. Это поможет исключить ряд распространенных ошибок.
Особенности написания кода, которые помогут исключить ошибку в транзакциях
Прежде всего нужно опираться на нюансы корректной обработки исключений:
- Метод «Начать транзакцию» должен быть вынесен за пределы «Попытка-Исключение».
- Действия, осуществляемые после вызова «Начать транзакцию» должны быть в пределах блока «Попытка». К этом также относится чтение, обработка или блокировка данных.
- Метод «Зафиксировать транзакцию» необходимо прописывать последним в блоке «Попытка» и до «Исключение».
- В блоке «Исключение» необходимо сначала обратиться к методу «Отменить транзакцию» и уже потом выполнять прочие действия.
- Если применяются вложенные транзакции, то в конце «Исключение» не лишним будет добавить оператора «Вызвать исключение».
- В «Исключения» следует добавить соответствующую запись об ошибке.
- Если транзакция неявная, то нет никакого смысла переходить к методу «Начать транзакцию». Некоторые также пробуют «обернуть» в явную транзакцию те операции, которые и вовсе не нуждаются в согласовании.
Решить проблему транзакций, в которых происходят ошибки, самостоятельно получается не всегда. Поэтому стоит попробовать выполнить простейшие действия – перезагрузить программу или очистить кэш. К более серьезным манипуляциям в 1С стоит переходить только при уверенности, что вы обладаете достаточным опытом.
В рамках подготовки к сертификации 1С «Эксперт» в преддверии двух очень важных и глобальных тем — блокировок и взаимоблокировок хотелось бы разобрать то, без чего невозможны вышеназванные понятия, — транзакция СУБД.
Что такое транзакция
Транзакция — логически связанная, неделимая последовательность действий. Транзакция может быть либо выполнена целиком, либо вообще не выполнена. Для фиксации транзакции в СУБД используется метод COMMIT.
Типичный пример транзакции — перевод денежных средств с одного счета на другой:
- начать транзакцию;
- прочесть количество денежных средств на счету номер 123;
- уменьшить баланс счета 123 на 100 рублей;
- сохранить баланс счёта номер 123;
- прочесть количество денежных средств на счету номер 321;
- увеличить баланс на 100 рублей;
- записать новое количество денежных средств на счете 321;
- зафиксировать транзакцию.
Как мы видим, если транзакция выполнена не полностью, то она не имеет смысла.
Ключевые требования (ACID) к транзакционной СУБД
Одним из наиболее распространённых наборов требований к транзакциям и транзакционным СУБД является набор ACID (Atomicity, Consistency, Isolation, Durability). Это те свойства, которыми должна обладать любая транзакция:
- Атомарность (Atomicity) — никакая транзакция не должна быть зафиксирована частично;
- Согласованность (Consistency) — система находится в согласованном состоянии до начала транзакции и должна остаться в согласованном состоянии после завершения транзакции;
- Изолированность (Isolation) — во время выполнения транзакции параллельные транзакции не должны оказывать влияние на её результат;
- Надежность (Durability) — в случая сбоя изменения, сделанные успешно завершённой транзакцией, должны остаться сохранёнными после возвращения системы в работу.
Транзакции в 1С
Транзакции в 1С 8.3 и 8.2 создаются как автоматически, так и описываются разработчиками.
Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания - попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>
С помощью метода ТранзакцияАктивна() можно узнать, активна ли транзакция.
Пример автоматической транзакции — обработка проведения документа, запись элемента справочника в базу данных, запись набора записей регистра сведений и т.д.
Разработчик может и сам создать транзакцию. Для выполнения действий в транзакции необходимо в код активировать её:
По окончании транзакции её необходимо зафиксировать:
Если Вы хотите отменить действия транзакции, необходимо выполнить метод:
1С не поддерживает вложенных транзакций. Поэтому, если Вы несколько раз открываете транзакцию, она «сливается» в одну. Если же Вы фиксируете или отменяете её, то это действие производится со всеми транзакциями, активируемыми ранее.
Если я не понятно расписал, рекомендую видеолекцию от коллег:
Проблемная накладная от 01.04.2021, внешних поводов для беспокойства не вызывает. Конфигурация типовая, версии 3.0.89, релиз не самый последний, но довольно свежий и стабильный. База файловая, работает один человек.
Беда подобной ошибки в том, что она не имеет четкого описания. Нет ссылок на проблемный код в конфигураторе. Нет отсылок к неверным реквизитам или пользовательским данным. С чего начинать поиски причины неясно.
Если спросить у интернета, то он выдаст массу статей и обсуждений. Они верные по сути, но не дают ответа на вопрос что делать. То есть они объясняют суть проблемы: при возникновении ошибки в одном из уровней многоуровневой транзакции, отменяется всё дерево. Связано это с некорректным написанием кода и неверным использованием механизма транзакций. Рекомендуется писать код правильно. Что делать пользователям типовых конфигураций не написано.
Пошёл стандартным путём:
- Закрыл все окна, открыл документ заново и попробовал провести. Безрезультатно.
- Сохранив предварительно базу, обновил её до 3.0.91 — последнего релиза. Вдруг это действительно ошибка в коде. Не помогло.
- Протестировал базу стандартными средствами ТиИ конфигуратора и утилитой chdbfl. Ошибок нет, не помогло.
- Очистил кэш в папках AppData\Roaming и AppData\Local (будьте внимательны, не удалите список баз!). Не помогло.
- Отключил ненужные фоновые задания. Остальным установил увеличенный интервал между попытками, расписание проверок сделал ежедневным. Впрочем, это явно лишнее — в списке активных пользователей была только одна строка. Действие не помогло.
- Стал размышлять: что ещё перепроводится при проведении поступления? Введённый на основании счет-фактура. При детальном изучении выяснилось, что у с/ф ошибочно была указана дата 01.01.2021. Т.е. документ попал в закрытый для редактирования период — дата запрета установлена на 31.03.2021.
Снял флаг запрета, поправил дату и указал верный номер. Всё провелось без ошибок.
Однако вопрос к коду типовой конфигурации остался: ошибка очень неявная. Вместо конкретного указания на невозможность перепровести счет-фактуру из-за установленной даты запрета, пользователь видит неинформативную надпись общего характера. Как так получается, что 1С игнорирует собственные стандарты разработки затрудняя поиск источника проблем не только пользователю, но и специалистам — загадка.
Небольшое пояснение. У 1С есть две похожие ошибки: "Объект изменен другим пользователем/ в другой транзакции" и "Ошибка блокировки транзакции". Они имеют пару похожих формулировок, но все они возникают когда записываемый объект занят другим пользователем. Это может быть как физический пользователь, так и регламентное задание. Частный случай — дважды открытый документ или элемент справочника. Именно для исключения этих ситуаций присутствуют действия в п. 1 и п. 5.
Если статья оказалась полезной, вы можете поддержать блог, отправив символическую сумму через форму ниже. Ваша поддержка вдохновляет меня на создание новых статей.
Заголовок вышел броским, но накипело. Сразу скажу, что речь пойдет об 1С. Дорогие 1С-ники, вы не умеете работать с транзакциями и не понимаете что такое исключения. К такому выводу я пришел, просматривая большое количество кода на 1С, рождаемого в дебрях отечественного энтерпрайза. В типовых конфигурациях с этим все достаточно хорошо, но ужасающее количество заказного кода написано некомпетентно с точки зрения работы с базой данных. Вы когда-нибудь видели у себя ошибку "В данной транзакции уже происходили ошибки"? Если да — то заголовок статьи относится и к вам. Давайте под катом разберемся, наконец, что такое транзакции и как правильно с ними обращаться, работая с 1С.
Почему надо бить тревогу
Для начала, давайте разберемся, что же такое представляет собой ошибка "В данной транзакции уже происходили ошибки". Это, на самом деле, предельно простая штука: вы пытаетесь работать с базой данных внутри уже откаченной (отмененной) транзакции. Например, где-то был вызван метод ОтменитьТранзакцию, а вы пытаетесь ее зафиксировать.
Почему это плохо? Потому что данная ошибка ничего не говорит вам о том, где на самом деле случилась проблема. Когда в саппорт от пользователя приходит скриншот с таким текстом, а в особенности для серверного кода, с которым интерактивно не работает человек — это… Хотел написать "критичная ошибка", но подумал, что это buzzword, на который уже никто не обращает внимания…. Это задница. Это ошибка программирования. Это не случайный сбой. Это косяк, который надо немедленно переделывать. Потому что, когда у вас фоновые процессы сервера встанут ночью и компания начнет стремительно терять деньги, то "В данной транзакции уже происходили ошибки" это последнее, что вы захотите увидеть в диагностических логах.
Есть, конечно, вероятность, что технологический журнал сервера (он ведь у вас включен в продакшене, да?) как-то поможет диагностировать проблему, но я сейчас навскидку не могу придумать вариант — как именно в нем найти реальную причину указанной ошибки. А реальная причина одна — программист Вася получил исключение внутри транзакции и решил, что один раз — не карабас "подумаешь, ошибка, пойдем дальше".
Что такое транзакции в 1С
Неловко писать про азбучные истины, но, видимо, немножго придется. Транзакции в 1С — это то же самое, что транзакции в СУБД. Это не какие-то особенные "1С-ные" транзакции, это и есть транзакции в СУБД. Согласно общей идее транзакций, они могут либо выполниться целиком, либо не выполниться совсем. Все изменения в таблицах базы данных, выполненные внутри транзакции, могут быть разом отменены, как будто ничего не было.
Далее, нужно понимать, что в 1С не поддерживаются вложенные транзакции. Собственно говоря, они не поддерживаются не "в 1С", а вообще не поддерживаются. По-крайней мере, теми СУБД, с которыми умеет работать 1С. Вложенных транзакций, например, нет в MS SQL и Postgres. Каждый "вложенный" вызов НачатьТранзакцию просто увеличивает счетчик транзакций, а каждый вызов "ЗафиксироватьТранзакцию" — уменьшает этот счетчик. Данное поведение описано в множестве книжек и статей, но выводы из этого поведения, видимо, разобраны недостаточно. Строго говоря, в SQL есть т.н. SAVEPOINT, но 1С их не использует, да и вещь это достаточно специфичная.
Здесь и далее, специально для Воинов Истинной Веры, считающих, что код должен писаться только на английском, под спойлерами будет приведен аналог кода в англоязычном синтаксисе 1С.
На самом деле, нет. Мне совершенно не хочется дублировать примеры на английском только ради того, чтобы потешить любителей холиваров и священных войн.
Вы же наверняка пишете такой код, да? Приведенный пример кода содержит ошибки. Как минимум, три. Знаете какие? Про первую я скажу сразу, она связана с объектными блокировками и не имеет отношения непосредственно к транзакциям. Про вторую — чуть позже. Третья ошибка — это deadlock, который возникнет при параллельном исполнении этого кода, но это тема для отдельной статьи, ее рассматривать сейчас не будем, дабы не усложнять код. Ключевое слово для гугления: deadlock управляемые блокировки.
Обратите внимание, простой ведь код. Такого в ваших 1С-системах просто вагон. И он содержит сразу, как минимум, 3 ошибки. Задумайтесь на досуге, сколько ошибок есть в более сложных сценариях работы с транзакциями, написанных вашими программистами 1С :)
Объектные блокировки
Итак, первая ошибка. В 1С существуют объектные блокировки, так называемые "оптимистические" и "пессимистические". Кто придумал термин, не знаю, убил бы :). Совершенно невозможно запомнить, какая из них за что отвечает. Подробно про них написано здесь и здесь, а также в прочей IT-литературе общего назначения.
Суть проблемы в том, что в указанном примере кода изменяется объект базы данных, но в другом сеансе может сидеть интерактивный пользователь (или соседний фоновый поток), который тоже будет менять этот объект. Здесь один из вас может получить ошибку "запись была изменена или удалена". Если это произойдет в интерактивном сеансе, то пользователь почешет репу, ругнется и попробует переоткрыть форму. Если это произойдет в фоновом потоке, то вам придется искать это в логах. А журнал регистрации, как вы знаете, медленный, а ELK-стек для журналов 1С у нас в отрасли настраивают единицы… (мы, к слову, входим в число тех, кто настраивает и другим помогает настраивать :))
Короче говоря, это досадная ошибка и лучше, чтобы ее не было. Поэтому, в стандартах разработки четко написано, что перед изменением объектов необходимо ставить на них объектную блокировку методом "ОбъектСправочника.Заблокировать()". Тогда параллельный сеанс (который тоже должен так поступить) не сможет начать операцию изменения и получит ожидаемый, управляемый отказ.
А теперь про транзакции
С первой ошибкой разобрались, давайте перейдем ко второй.
Если не предусмотреть проверку исключения в этом методе, то исключение (например, весьма вероятное на методе "Записать()") выбросит вас из данного метода без завершения транзакции. Исключение из метода "Записать" может быть выброшено по самым разным причинам, например, сработают какие-то прикладные проверки в бизнес-логике, или возникнет упомянутая выше объектная блокировка. Так или иначе, вторая ошибка гласит: код, начавший транзакцию, не несет ответственность за ее завершение.
Именно так я бы назвал эту проблему. В нашем статическом анализаторе кода 1С на базе SonarQube мы даже отдельно встроили такую диагностику. Сейчас я работаю над ее развитием, и фантазия программистов 1С, чей код попадает ко мне на анализ, порой приводит меня в шок и трепет…
Почему? Потому что выброшенное наверх исключение внутри транзакции в 90% случаев не даст эту транзакцию зафиксировать и приведет к ошибке. Следует понимать, что 1С автоматически откатывает незавершенную транзакцию только после возвращения из скриптового кода на уровень кода платформы. До тех пор, пока вы находитесь на уровне кода 1С, транзакция остается активной.
Поднимемся на уровень выше по стеку вызовов:
Смотрите, что получается. Наш проблемный метод вызывается откуда-то извне, выше по стеку. На уровне этого метода разработчик понятия не имеет — будут ли какие-то транзакции внутри метода ОченьПолезныйИВажныйКод или их не будет. А если будут — то будут ли они все завершены… Мы же все тут за мир и инкапсуляцию, верно? Автор метода "ВажныйКод" не должен думать про то, что именно происходит внутри вызываемого им метода. Того самого, в котором некорректно обрабатывается транзакция. В итоге, попытка поработать с базой данных после выброса исключения изнутри транзакции, с высокой вероятностью приведет к тому, что "В данной транзакции бла-бла…"
Размазывание транзакций по методам
Второе правило "транзакционно-безопасного" кода: счетчик ссылок транзакций в начале метода и в его конце должен иметь одно и то же значение. Нельзя начинать транзакцию в одном методе и завершать ее в другом. Из этого правила, наверное, можно найти исключения, но это будет какой-то низкоуровневый код, который пишут более компетентные люди. В общем случае так писать нельзя.
Выше — неприемлемый говнокод. Нельзя писать методы так, чтобы вызывающая сторона помнила и следила за возможными (или вероятными — как знать) транзакциями внутри других методов, которые она вызывает. Это нарушение инкапсуляции и разрастание спагетти-кода, который невозможно трассировать, сохраняя рассудок.
Особенно весело вспомнить, что реальный код намного больше синтетических примеров из 3-х строчек. Выискивать начинающиеся и завершающиеся транзакции по шести уровням вложенности — это прям мотивирует на задушевные беседы с авторами.
Вернемся к исходному методу и попытаемся его починить. Сразу скажу, что объектную блокировку мы чинить пока не будем, просто, чтобы не усложнять код примера.
Первый подход типичного 1С-ника
Обычно программисты 1С знают, что при записи может быть выдано исключение. А еще они боятся исключений, поэтому стараются их все перехватывать. Например, вот так:
Однако, опытный 1С-ник здесь скажет, что нет, лучше не стало. По сути ничего не поменялось, а может даже стало и хуже. В методе "Записать()" платформа 1С сама начнет транзакцию записи, и эта транзакция будет уже вложенной по отношению к нашей. И если в момент работы с базой данных 1С свою транзакцию откатит (например, будет выдано исключение бизнес-логики), то наша транзакция верхнего уровня все равно будет помечена как "испорченная" и ее нельзя будет зафиксировать. В итоге этот код так и останется проблемным, и при попытке фиксации выдаст "уже происходили ошибки".
А теперь представьте, что речь идет не о маленьком методе, а о глубоком стеке вызовов, где в самом низу кто-то взял и "выпустил" начатую транзакцию из своего метода. Верхнеуровневые процедуры могут и понятия не иметь, что кто-то там внизу начинал транзакции. В итоге, весь код валится с невнятной ошибкой, которую расследовать невозможно в принципе.
Код, который начинает транзакцию, обязан завершить или откатить ее. Не взирая ни на какие исключения. Каждая ветка кода должна быть исследована на предмет выхода из метода без фиксации или отмены транзакции.
Методы работы с транзакциями в 1С
Не будет лишним напомнить, что вообще 1С предоставляет нам для работы с транзакциями. Это всем известные методы:
- НачатьТранзакцию()
- ЗафиксироватьТранзакцию()
- ОтменитьТранзакцию()
- ТранзакцияАктивна()
Первые 3 метода очевидны и делают то, что написано в их названии. Последний метод — возвращает Истину, если счетчик транзакций больше нуля.
И есть интересная особенность. Методы выхода из транзакции (Зафиксировать и Отменить) выбрасывают исключения, если счетчик транзакций равен нулю. То есть, если вызвать один из них вне транзакции, то возникнет ошибка.
Как правильно пользоваться этими методами? Очень просто: надо прочитать сформулированное выше правило: код, начавший транзакцию, должен нести ответственность за ее завершение.
Как же соблюсти это правило? Давайте попробуем:
Выше мы уже поняли, что метод ДелаемЧтоТо — потенциально опасен. Он может выдать какое-то исключение, и транзакция "вылезет" наружу из нашего метода. Окей, добавим обработчик возможного исключения:
Так, стоп… Если мы просто прокидываем исключение дальше, то зачем тут вообще нужна Попытка? А вот зачем: правило заставляет нас обеспечить завершение начатой нами транзакции.
Теперь, вроде бы, красиво. Однако, мы ведь помним, что не доверяем коду ДелаемЧтоТо(). Вдруг там внутри его автор не читал этой статьи, и не умеет работать с транзакциями? Вдруг он там взял, да и вызвал метод ОтменитьТранзакцию или наоборот, зафиксировал ее? Нам очень важно, чтобы обработчик исключения не породил нового исключения, иначе исходная ошибка будет потеряна и расследование проблем станет невозможным. А мы помним, что методы Зафиксировать и Отменить могут выдать исключение, если транзакция не существует. Здесь-то и пригождается метод ТранзакцияАктивна.
Финальный вариант
Наконец, мы можем написать правильный, "транзакционно-безопасный" вариант кода. Вот он:
**UPD: в комментариях предложен более безопасный вариант, когда ЗафиксироватьТранзакцию расположен внутри блока Попытка. Здесь приведен именно этот вариант, ранее Фиксация располагалась после блока Попытка-Исключение.
Постойте, но ведь не только "ОтменитьТранзакцию" может выдавать ошибки. Почему же тогда "ЗафиксироватьТранзакцию" не обернут в такое же условие с "ТранзакцияАктивна"? Опять же, по тому же самому правилу: код, начавший транзакцию, должен нести ответственность за ее завершение. Наша транзакция необязательно самая первая, она может быть вложенной. На нашем уровне абстракции мы обязаны заботиться только о нашей транзакции. Все прочие должны быть нам неинтересны. Они чужие, мы не должны нести за них ответственность. Именно НЕ ДОЛЖНЫ. Нельзя предпринимать попыток выяснения реального уровня счетчика транзакций. Это опять нарушит инкапсуляцию и приведет к "размазыванию" логики управления транзакциями. Мы проверили активность только в обработчике исключения и только для того, чтобы убедиться, что наш обработчик не породит нового исключения, "прячущего" старое.
Чек-лист рефакторинга
Давайте рассмотрим несколько наиболее распространенных ситуаций, требующих вмешательства в код.
Паттерн:
Обернуть в "безопасную" конструкцию с Попыткой, Проверкой активности и пробросом исключения.
Паттерн:
Анализ и Рефакторинг. Автор не понимал, что делает. Начинать вложенные транзакции можно безопасно. Не нужно проверять условие, нужно просто начать вложенную транзакцию. Ниже по модулю он наверняка еще там извращается с их фиксацией. Это гарантированный геморрой.
Примерно похожий вариант:
аналогично: фиксация транзакции по условию — это странно. Почему тут условие? Что, кто-то иной мог уже зафиксировать эту транзакцию? Повод для разбирательства.
Паттерн:
- ввести управляемую блокировку во избежание deadlock
- ввести вызов метода Заблокировать
- обернуть в "попытку", как показано выше
Паттерн:
В заключение
Я, как вы уже, наверное, догадались, отношусь к людям, любящим платформу 1С и разработку на ней. К платформе, разумеется, есть претензии, особенно в среде Highload, но в общем и целом, она позволяет недорого и быстро разрабатывать очень качественные корпоративные приложения. Давая из коробки и ORM, и GUI, и веб-интерфейс, и Reporting, и много чего еще. В комментариях на Хабре обычно пишут всякое высокомерное, так вот, ребята — основная проблема 1С, как экосистемы — это не платформа и не вендор. Это слишком низкий порог вхождения, который позволяет попадать в отрасль людям, не понимающим, что такое компьютер, база данных, клиент-сервер, сеть и всякое такое. 1С сделала разработку корпоративных приложений слишком легкой. Я за 20 минут могу написать на ней учетную систему для закупок/продаж с гибкими отчетами и веб-клиентом. После этого, мне несложно подумать о себе, что и на больших масштабах можно писать примерно так же. Как-то там 1С сама все внутри сделает, не знаю как, но наверное сделает. Напишу-ка я "НачатьТранзакцию()".
И знаете — самое главное, что это прекрасно. Простота разработки в 1С позволяет моментально реализовывать бизнес-идеи и встраивать их в процессы компании. Потом всегда можно отрефакторить, главное понимать как. И если вдруг вам нужна помощь в аудите вашей "медленной 1С" — обращайтесь к специалистам по оптимизации. Она совсем не медленная.
Довольно часто пользователи программы 1С Предприятие 8 сталкиваются с ошибкой «В данной транзакции уже происходили ошибки».
В данной транзакции уже происходили ошибки
Давайте разберемся в чем причина.
1. Причина ошибки в 1С Предприятие 8.3
С технической точки зрения эта ошибка в 1С:Предприятие 8.3 возникает в транзакции в момент первого обращения к базе данных после обработки исключительной ситуации операторами (Попытка-Исключение).
Ниже на рисунке продемонстрирован пример, когда при записи объекта «Объект_1» вызывается исключительная ситуация, при этом ошибка возникает в строке «Ссылка_2.Наименование», т.к. осуществляется запрос к базе данных в объектной модели данных. И не важно, запись это или чтение.
Возникновение ошибки в 1С Предприятие 8.3 при записи объекта
Причем в попытке-исключении обрабатываться операция, которая также выполняется в транзакции. Чаще всего это сочетание явных и неявных транзакций, т.е. транзакций, вызванных оператором НачатьТранзакцию явно и транзакций, вызванных платформой неявно (например, при записи объекта).
Как известно, система 1С:Предприятие 8.3 не поддерживает вложенных транзакций, но допускает организацию вложенной конструкции нескольких транзакций. В нашем примере явный вызов транзакции оператором НачатьТранзакцию – транзакция 1 уровня, а неявная транзакция записи – транзакция 2 уровня и т.д. Возникновение ошибки на нижних уровнях запрещает успешное завершение транзакции 1 уровня. Другими словами, откатывается все «дерево транзакций».
В чем же здесь проблема?
2. Почему ошибку «В данной транзакции уже происходили ошибки» надо устранить
Во-вторых, воспроизведение ошибки и ее отладка администратором тоже будет не простым занятием. Дело в том, что ошибка возникает в момент первого обращения к базе данных, т.е. в журнале регистрации будет зафиксирована именно эта строка. Хотя сама причина этой ошибки находиться в коде на самом нижнем уровне. В нашем примере «Объект_1» может содержать различные проверки перед записью, «завернутые» в конструкцию «Попытка-Исключение», которые, в свою очередь, могут также иметь глубокую иерархию вызовов процедур и функций. Попробуй разберись.
В-третьих, суть этой ошибки – некорректный код. А если быть более точным – несоблюдение требований к написанию кода с использованием транзакций.
Как решить эту проблему в 1С:Предприятие?
3. Как устранить ошибку в программе 1С Предприятие 8
Основным требованием к написанию кода с использованием транзакций, непосредственно связанным с ошибкой «В данной транзакции уже происходили ошибки» в 1С:Предприятие, являются правила использования обработки исключения:
1. Метод НачатьТранзакцию должен находиться за пределами блока Попытка-Исключение;
2. Все действия, выполняемые после вызова метода НачатьТранзакцию, должны находиться в одном блоке Попытка, в том числе чтение, блокировка и обработка данных;
3. Метод ЗафиксироватьТранзакцию должен идти последним в блоке Попытка перед оператором Исключение;
4. В блоке Исключение нужно сначала вызвать метод ОтменитьТранзакцию, а затем выполнять другие действия;
6. В блоке исключения рекомендуется сделать запись об ошибке средствами встроенного языка.
Общая схема во вложенной транзакции:
Схема вложенной транзакции в системе 1С:Предприятие 8.3
Пример вложенной транзакции для решения ошибки «В данной транзакции уже происходили ошибки»
Специалист компании «Кодерлайн»
Вас могут заинтересовать следующие статьи:
Читайте также: