1с ошибка обращения данным при транзакции

Обновлено: 07.07.2024

Последние несколько дней база стала давать предупреждение:При выполенении произошла ошибка! Таблица 1SJourn Ошибка обращения к данным при транзакиции, выполняемой другим пользователем.Повторить попытку? [Да Нет].Появляется при проведении доков, выполнении отчетов. Если кто встречал такую фичу, подскажите как лечить

Ошибка обращения к данным при транзакиции, выполняемой другим пользователем.

Плохо смотрел. Ищи: Ошибка обращения к данным при транзакции 1С

Спасиб, я глянул. Насколько понял, коллизия призаписи доков в табицу, используемую для УРБД. Но, почему она стала появляться? Раньше ведь не было..

См. Ошибка <одновременного> обращения к <различным> данным при транзакиции, выполняемой другим пользователем. Темерь понятно?

Почему "к <различным>". Наверное хотел сказать "к одним и тем же"?

В 1SJORn хранятся записи используемые урбд.Непонятно почему это появилось и что с ним делать;)

. Да тех, кто в бронепоезде: несколько пользователей хотят одновременно получить одни данные. Возникает транзакция (блокировка данных). Теперь-то понятно?

Rnj-nj gsnftncz ljcnexfnmcz lj lfyys[? rjnjhst ,kjrbhjdfys nhfypfrwbtq/

От тех, кто в бронепоезде: Почему этой ошибки раньше не было?

Сейчас только один пользователь или кто-то что-то проводит?

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

Ничего я не впиндюривал, я конфу сам полностью писал.

+ Разные пользователи пытаются обратиться к одним и тем-же данным, которые блокированы кем-то в транзакции.

епрст, пользователей сколько было, столько и осталось, раньше этого предупреждения не было, а сейчас све юзеры ко мне бегут дружной толпой и жалуются

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

+ Проводи по сетке, зачастую локально у тебя все летает, а по сети тормозит (если, например, запрос в цикл засунул - локально будет пару секунд проводится, а по сетке пару минут)

Кстати очень может быть, у меня в одном регистре висят огромные непроходящие минуса, из-за этого все доки долго черепятся

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

+ Короче с такой надписью всех блокирует кусок НачатьТранзакцию; . ЗафиксироватьТранзакцию; либо ОбработкаПроведения - это такая же транзакция, только явно не написано.

НачатьТранзакцию нигде нет, скорее всего обработка проведения подвешивает все..

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

Как вариант можно их в терминал загнать - проведение ускорится в разы, но код свой анализировать все же надо, где-то косяк.

Ошибки базы данных и транзакции

При работе с базой данных могут происходить ошибки. В 1С:Предприятии 8 ошибки базы данных подразделяются на следующие две категории:

К невосстановимым относятся такие ошибки базы данных, при возникновении которых функционирование 1С:Предприятия 8 может быть серьезно нарушено. Поэтому, во избежание более серьезных неприятностей (например, порчи данных), при возникновении невосстановимой ошибки выполнение 1С:Предприятия 8 прекращается. Если невосстановимая ошибка базы данных произошла в процессе выполнения транзакции, то все изменения сделанные в рамках этой транзакции отменяются.

При возникновении восстановимой ошибки считается, что серьезных нарушений в работе 1С:Предприятия 8 не произошло и работа может быть продолжена, но сама вызвавшая ошибку операция прекращается, и вызывается исключение, которое может быть перехвачено и обработано средствами встроенного языка. Казалось бы, все понятно. Но есть тонкость. Если восстановимая ошибка базы данных произошла в процессе выполнения транзакции, то, вне зависимости от того, было исключение, вызванное этой ошибкой, перехвачено и обработано или нет, транзакция уже не может быть продолжена или зафиксирована. Единственная операция с базой данных, которую можно произвести в такой ситуации - это отмена транзакции. Таким образом, приведенный фрагмент кода не вполне корректен:

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

Как же выйти из такой ситуации? Общее правило состоит в следующем: если при выполнении транзакции имели место ошибки базы данных, то следует отменить всю транзакцию в целом и, в случае необходимости, повторить попытку ее выполнения с самого начала. Таким образом, приведенный выше пример должен быть переработан следующим образом:

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

Следует однако сделать предостережение. Дело в том, что в рамках уже выполняемой транзакции можно обращаться к методам НачатьТранзакцию() , ЗафиксироватьТранзакцию() и ОтменитьТранзакцию() . Однако вызов метода НачатьТранзакцию() при уже выполняющейся транзакции не означает начала новой транзакции. В этом случае просто произойдет увеличение на 1 значения внутреннего счетчика транзакций. Метод НачатьТранзакцию() начинает новую транзакцию только в том случае, если значение внутреннего счетчика транзакций равно 0. Аналогично, обращение к методам ЗафиксироватьТранзакцию() или ОтменитьТранзакцию() приводит к реальному завершению транзакции только в том случае, если значение внутреннего счетчика транзакций равно 1. Если при значении счетчика транзакций большем 1 произойдет обращение к методу ЗафиксироватьТранзакцию() , то значение счетчика будет просто уменьшено на 1:

Если же при значении счетчика траназкций большем 1 произойдет обращение к методу ОтменитьТранзакцию() , то значение счетчика транзакций не только будет уменьшено на 1, но и произойдет установка признака, не позволяющего зафиксировать результаты выполнения всей транзакции в целом. И последующее обращение к методу ЗафиксироватьТранзакцию() , выполняемое при значении счетчика транзакций равном 1, фактически приведет к отмене транзакции:

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


Заголовок вышел броским, но накипело. Сразу скажу, что речь пойдет об 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: в комментариях предложен более безопасный вариант, когда ЗафиксироватьТранзакцию расположен внутри блока Попытка. Здесь приведен именно этот вариант, ранее Фиксация располагалась после блока Попытка-Исключение.

Постойте, но ведь не только "ОтменитьТранзакцию" может выдавать ошибки. Почему же тогда "ЗафиксироватьТранзакцию" не обернут в такое же условие с "ТранзакцияАктивна"? Опять же, по тому же самому правилу: код, начавший транзакцию, должен нести ответственность за ее завершение. Наша транзакция необязательно самая первая, она может быть вложенной. На нашем уровне абстракции мы обязаны заботиться только о нашей транзакции. Все прочие должны быть нам неинтересны. Они чужие, мы не должны нести за них ответственность. Именно НЕ ДОЛЖНЫ. Нельзя предпринимать попыток выяснения реального уровня счетчика транзакций. Это опять нарушит инкапсуляцию и приведет к "размазыванию" логики управления транзакциями. Мы проверили активность только в обработчике исключения и только для того, чтобы убедиться, что наш обработчик не породит нового исключения, "прячущего" старое.

Чек-лист рефакторинга

Давайте рассмотрим несколько наиболее распространенных ситуаций, требующих вмешательства в код.

Паттерн:

Обернуть в "безопасную" конструкцию с Попыткой, Проверкой активности и пробросом исключения.

Паттерн:

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

Примерно похожий вариант:

аналогично: фиксация транзакции по условию — это странно. Почему тут условие? Что, кто-то иной мог уже зафиксировать эту транзакцию? Повод для разбирательства.

Паттерн:

  1. ввести управляемую блокировку во избежание deadlock
  2. ввести вызов метода Заблокировать
  3. обернуть в "попытку", как показано выше

Паттерн:

В заключение

Я, как вы уже, наверное, догадались, отношусь к людям, любящим платформу 1С и разработку на ней. К платформе, разумеется, есть претензии, особенно в среде Highload, но в общем и целом, она позволяет недорого и быстро разрабатывать очень качественные корпоративные приложения. Давая из коробки и ORM, и GUI, и веб-интерфейс, и Reporting, и много чего еще. В комментариях на Хабре обычно пишут всякое высокомерное, так вот, ребята — основная проблема 1С, как экосистемы — это не платформа и не вендор. Это слишком низкий порог вхождения, который позволяет попадать в отрасль людям, не понимающим, что такое компьютер, база данных, клиент-сервер, сеть и всякое такое. 1С сделала разработку корпоративных приложений слишком легкой. Я за 20 минут могу написать на ней учетную систему для закупок/продаж с гибкими отчетами и веб-клиентом. После этого, мне несложно подумать о себе, что и на больших масштабах можно писать примерно так же. Как-то там 1С сама все внутри сделает, не знаю как, но наверное сделает. Напишу-ка я "НачатьТранзакцию()".

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

В статье описаны возможные ошибки, возникающие при обмене данными между программами 1С, а также варианты решения этих ошибок.

Общие ошибки, возникающие в 1С при работе с XML

Не установлен MS XML Core Services 4.0

На компьютере не установлен Microsoft XML Core Services 4.0, используемый "1С:Предприятием 8" для работы с XML.

Попробуйте установить Microsoft XML Core Services 4.0. При установке "1С:Предприятия 8" Microsoft XML Core Services 4.0 устанавливается автоматически.

Ошибка разбора XML

Ошибка, возникающая при синтаксическом анализе данных XML в процессе чтения. Все ошибки, определенные в SAX2, трансформируются в данную ошибку, генерируемую платформой "1С:Предприятие 8".

Проверьте правильность оформления и синтаксис данных XML.

Ошибочный порядок записи XML

Методы записи содержимого документа XML вызываются в неправильном порядке. Например, запись атрибута вызывается после записи текста элемента.

Текст XML содержит недопустимые символы

Записываемый текст XML содержит недопустимые символы.

Текст XML должен соответствовать требованиям к XML.

Недопустимое имя XML

Записываемое имя XML содержит недопустимые символы.

Имя XML должно соответствовать требованиям к XML.

Пустое значение URI допустимо только для пространства имен по умолчанию

Производится попытка записать соответствие пространства имен, в котором URI пространства имен, представленному пустой строкой, соответствует непустой префикс.

Значение URI пространства имен должно соответствовать рекомендации Namespaces in XML.

Переопределение пространства имен по умолчанию для текущего элемента XML недопустимо

Текущий записываемый элемент не относится ни к какому пространству имен. Поэтому для него недопустимо определение непустого пространства имен по умолчанию.

Переопределение пространства имен по умолчанию для элемента, не относящегося ни к какому пространству имен – запрещено.

Ошибка преобразования данных XML

Ошибка возникает вследствие нарушения структуры передаваемых данных.

Значения данного типа не могут быть представлены в XML

Производится попытка записи в XML значения, для типа которого не определена процедура записи в XML. Или производится попытка чтения из XML значения неизвестного типа или типа, для которого не определена процедура чтения из XML.

Ошибка данных XML

Ошибка возникает при получении некорректных данных из источника XML или же в случаях неудачного считывания из базы данных содержимого объекта, данные которого должны быть прочитаны из источника XML: блокировка объекта или же отсутствие прав на чтение данного объекта.

Например, чтение существующего элемента справочника: если элемент справочника является группой, а было прочитано то, что является элементом, будет сгенерирована данная ошибка.

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

Ситуации, возникающие при обмене данными в рамках распределенной информационной базы в 1С

Узел не является узлом распределенной ИБ

При вызове одного из методов встроенного языка, относящегося к распределенной ИБ, значение переданного параметра - узла плана обмена - не принадлежит плану обмена с установленным признаком "Распределенная информационная база".

Необходимо убедиться в правильности передаваемого в метод параметра.

Начальный образ может быть выгружен только во вновь созданную или пустую ИБ

По указанному месторасположению начального образа уже существует другая информационная база.

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

Ошибка формата представления изменений

Попытка приема изменений от неизвестной конфигурации

Искажены изменения конфигурации!

Конфигурация узла распределенной ИБ не соответствует ожидаемой!

Изменения конфигурации не могут быть получены из подчиненного узла распределенной ИБ

Из главного узла распределенной ИБ получены изменения конфигурации

Из главного узла получены изменения конфигурации.

Данные не входят в состав плана обмена

Если не нашли решения своих ошибок или хотите воспользоваться услугами экспертов для настройки обмена данными между программами 1С, проверки и исправления ошибок, звоните в офисы Первого Бита.

Читайте также: