1с ошибка при вызове метода контекста прочитатьизменения
Гружу файл. Просмотрел как грузятся проблемные места все нормально.
Находятся элементы и прописываются.
Отлавливаю проблему.
Когда функция просто не отрабатывает, поиска по наименованию (((
Хотя так же все нормально передается туда для поиска.
(26) Ну так найдена была бы пустая ссылка, но не ошибка.
То работает то нет. Так же строка передается!
Глупый вопрос: зачем тогда для каждой строки делать поиск для справочника?
Сделай соответствие символьного представления и ссылки
(24) все же сомнения терзают, там не пробел будет, а нечитаемый неправильный вызывающий ошибку символ, который СОКРЛП не отловит и СТРЗаменить
(44) Сейчас отлаживаю эту процедуру, по нажатию кнопке. Ошибки в ней.
Вот. Все работает. Но иногда идет эта ошибка и все, на таких же данны!
(48) я так и останавливаюсь на строке 2000 с лишним
(51)(52) Да можно многого добавить, но я же смотрю в отладчике, в функцию передаются верные данные, а идет ошибка.
Добавлю конечно проверки.
(55) не знаю. у меня правило, если происходит неведомая херня, нужно сначала делать это, а потом только лезть за бубном
Кэш почищу сейчас догрузится.
Стоит галка останавливаться по ошибке.
Ошибка видимо возникает при записи элемента.
Я смотрю что там в нем, вижу проблему в единицах измерения и родителе.
Но из за чего не пойму.
Или ошибка заполнения обязательных на уровне платформы полей: наименование, владелец (если справочник подчинённый) и тд
(71) У меня же нет попытки исключения?
Да ранее я вижу что в родителе и единицах измерения.
Но туда идут нормальные данные. Буду разбираться.
Видимо энергия ушла.
сейчас вот с этим буду бороться что это пока не знаю
(83) в общем пройдись по справочнику номенклатуры где-то есть одинаковое наименование у элемента и группы. Или если самому лень, посади за проверку девочку-восьмиклассницу, пусть проштудирует справочник от и до.
(81) Не должно такого быть.
(84) Гружу структуру из другой базы. Я пока не могу записать ни одного элемента. Так как грузится в транзакции.
Мне не лень. Я пытаюсь разобраться. Но такого не могло в принципе быть. Надеюсь докапаться до проблемы.
(84) смотрю в файле не нахожу.
Поставил останавливаться по ошибке.
Остановка же будет на проблемном элементе?
Ну вот, пока я в отладчеке не увидел там проблемы.
Ошибка при вызове метода контекста (ПрочитатьИзменения): Данные принимаются от узла с другим набором расширений, меняющих структуру данных. Необходимо произвести перенос расширений конфигурации в узел. При выгрузки первоначального образа вылетает по не понятным причинам.
Проблема продолжается и по-прежнему актуальна даже на релизе платформы 1С:Предприятие 8.3 (8.3.20.1549).
Продолжаю темы в публикациях:
Порядок действий аналогичен:
В данной публикации рабочая обработка для привязки и отвязки главного узла для Управляемых Форм.
Вариант 1
Последовательность действий:
- выгружаем из центральной базы конфигурацию в cf-файл;
- отвязываем периферийную базу от главного узла, с помощью обработки
- заменяем конфигурацию периферийной базы на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла".
- Привязываем периферийную базу обратно к главному узлу РИБ, с помощью обработки
Вариант 2
Делайте всё как в предыдущих публикациях, Но только перед этим основную базу выгружайте в dt и загружайте обратно после проделанных изменений с заменой *cf. После единичного обмена может появиться другая проблема: "Конфигурация не соответствует ожидаемой".
В основной базе конфигурацию снимайте *CF. В РИБе снимайте Главный узел с помощью прикрепленной обработки.
Обновляйте конфигурацию в РИБе путем загрузки cf. Ставьте обратно Главный узел. После, обмены стабильно работают.
Вариант 3
Когда не удается выгрузить первоначальный образ из-за присутствующих в ней дополнительных расширений и доработок.
Собственно, когда вылетает платформа по непонятным причинам или например "Аварийное завершение работы базы". Или
Ошибка при вызове метода контекста (ПрочитатьИзменения): Данные принимаются от узла с другим набором расширений, меняющих структуру данных.
Необходимо произвести перенос расширений конфигурации в узел.
Это прежде всего связано с недоработкой платформы и взаимодействием её с памятью. В подробности вникать ни к чему, так как всем нужен результат, но проблема явно остается платформенная и пока не доработана разработчиками.
Если реально присутствуют расширения, то делаем так:
1. Делаем всё на копии основной базы
3. Сохраняем все расширения путем выгрузки в файл. а затем Удаляем проблемные расширения, если нет понимания какое именно - удаляйте все.
4. Заходим в режим предприятия и делаем создание первоначального образа РИБа. Образ с вероятностью 99% должен будет создаться. (1% если конфигурация сломана, её следует вернуть на оригинальную)
4.1. Заходим в конфигуратор и загружаем DT из п.2
5. Далее заходим в созданный РИБ и отвязываем его от главного узла с помощью прикрепленной обработки.
6. Заходим в конфигуратор, Устанавливаем все расширения из п.3, обновляем конфигурацию БД РИБа
7. Заходим в режим предприятия РИБа - привязываем его к центральному узлу (все таже обработка)
8. Делаем синхронизацию в обеих базах. Будут ошибки - смотрим читаем журнал. Перезаходим в РИБ.
9. В РИБе полезно нажимать на кнопку "Выполнить сценарий". Конфигуратор должен быть в это время закрыт. Иначе будет ошибка блокировки смотреть в журнале.
После нескольких попыток базы должны будут синхронизироваться и все расширения должны привязаться от главного узла.
Добрый день. Есть РИБ с двумя базами. При выгрузки из центральной в перефирийную очень часто валится ошибка:
Ошибка при чтении изменений при обмене РИБ: Ошибка при вызове метода контекста (ПрочитатьИзменения): Ошибка преобразования данных XML: (тут путь к файлу и номер строки с ошибкой).
По строке искал ошибку, там все как и у других элементов, которые уже были прочитаны.
Если снимать регистрацию, и делать поменьше объем данных - обмен успешно завершается.
Платформа 8.3.10, конфигурация Комплексная автоматизация, редакция 1.1 (1.1.19.1).
(0)Отладчиком смотреть в каком месте ошибка, бывает что проблема в данных - например какой-ть кривой символ в наименовании элемента.
Сергиус, в отладчике падает при попытки чтения файла.
Всегда разные строки, ну и он даже на пустых валится.
В общем сама ошибка:
Чтение данных из файла обмена завершено с ошибками!
не пойму что тут может быть не так на 42 строчке с 6 символом?
(10) Cf основной выгрузил в перефирийную. Реквизиты полностью соответствуют, к тому же какой то контрагент выгружается, а какой то нет. Ошибки постоянно в разных полях, но это не могут быть данные, так как там обычное слова по типу "Поставщик" и тд. Либо пустая ссылка.
(15) на пустых и должен валиться, там проверка обычно на заполненность, если пусто, то валится. Например валюта не указана или еще что-то.
(17) Так он валится на стадии чтения самого файла, то есть там еще не доходит до проверки заполненности и тд.
(24) Конфигурация не озвучена, а в некоторых конфигурациях автоматический(!) обмен производится с использованием справочника "Сценарии синхронизации данных".
(27) Не не, писал в вопросе: Платформа 8.3.10, конфигурация Комплексная автоматизация, редакция 1.1 (1.1.19.1).
(25) Я вас возможно поражу, но файл, в котором случается ошибка есть копия файла обмена. Оба файла идентичны. Но за совет быть внимательнее, спасибо.
(0) видел похожую инфу в инете.
там плясали вокруг этих строк в файле
(34) ну там немного другое, это я делал когда свой cf заливал, центральная база не хотела обмениваться с периферийной как раз из за этих строк. Спасибо.
Если поможет - будешь рекламировать:-)
(39) Спасибо огромное!) Я другую немного написал, там основано на методе НайтиНедопустимыеСимволыXML, но к сожалению не она не ваша не нашла ничего.
(39)(41) никогда не видел что бы обмен валился от недопустимых символов.
надо копать в сторону "Если снимать регистрацию, и делать поменьше объем данных - обмен успешно завершается. " Искать что не так в данных
(30) "файл, в котором случается ошибка есть копия файла обмена. Оба файла идентичны" // Как определил?
(43)Просто у тебя не было никогда таких случаев. С русскими буками редко такое бывает.у нас в казахском алфавите есть несколько специфических букв.Вот они иногда гонят и не входят в разрешенные XML пределы символов
и валится он то на строчке НаименованиеПолное, то ДополнительноеОписание, то ГоловнойКонтрагент, с указанием на вполне адекватные символы.
фрагмент файла обмена(только контрагент):
Нашел решение проблемы, точнее ее исправление.
Нижеперечисленное делаю при помощи обработки ВыгрузкаЗагрузкаДанныхXML(выгружаю), удалению произвожу самописной.
У себя в базе нашел 4 таких контрагента, после вышеперечисленных действий с каждым справочник полностью обменялся.
В связи с чем хотелось бы спросить - с чем может быть связано данное поведение? У кого какие мысли?
(48) Удаляя и загружая объект, Вы исправляете ошибки, возникшие при записи объекта, которые, возможно, не выявляет ТИИ (оно не всесильно).
А если говорить "в общем случае", то.
Стандартный типовой обмен РИБ - это функционал платформы прежде всего. Раньше часто обращал внимание и не раз попадал на то, как платформу глючит на казалось бы не таких уж и больших объёмах данных. Ваше решение в (48) просто помогает обойти эту проблему (уменьшая объём данных и вынося конфликтные данные в отдельный обмен).
Ну, что я могу сказать по этому поводу. "Надо чаще обмениваться". Чем чаще обмен - тем меньше объём. Азбука :)
Можно, в принципе, попробовать изменить настройку обмена, уходя из исполнения в рамках единой транзакции, на подбор в сторону уменьшения количества объектов в транзакции до тех пор, пока не уйдёт ошибка.
(49) "Удаляя и загружая объект, Вы исправляете ошибки, возникшие при записи объекта, которые, возможно, не выявляет ТИИ (оно не всесильно). " - тоже предполагал, но все таки интересно было кто еще что скажет)
Про частоту обмена - да, согласен, но базы решили объединить внезапно, в которых уже заведено много данных, и велись они обособленно.
Да и самое главное, ошибка ушла, справочники обмениваются, пока что все хорошо)
Ошибка при вызове метода контекста (ПрочитатьИзменения): Данные принимаются от узла с другим набором расширений, меняющих структуру данных. Необходимо произвести перенос расширений конфигурации в узел. При выгрузки первоначального образа вылетает по не понятным причинам.
Проблема продолжается и по-прежнему актуальна даже на релизе платформы 1С:Предприятие 8.3 (8.3.20.1549).
Продолжаю темы в публикациях:
Порядок действий аналогичен:
В данной публикации рабочая обработка для привязки и отвязки главного узла для Управляемых Форм.
Вариант 1
Последовательность действий:
- выгружаем из центральной базы конфигурацию в cf-файл;
- отвязываем периферийную базу от главного узла, с помощью обработки
- заменяем конфигурацию периферийной базы на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла".
- Привязываем периферийную базу обратно к главному узлу РИБ, с помощью обработки
Вариант 2
Делайте всё как в предыдущих публикациях, Но только перед этим основную базу выгружайте в dt и загружайте обратно после проделанных изменений с заменой *cf. После единичного обмена может появиться другая проблема: "Конфигурация не соответствует ожидаемой".
В основной базе конфигурацию снимайте *CF. В РИБе снимайте Главный узел с помощью прикрепленной обработки.
Обновляйте конфигурацию в РИБе путем загрузки cf. Ставьте обратно Главный узел. После, обмены стабильно работают.
Вариант 3
Когда не удается выгрузить первоначальный образ из-за присутствующих в ней дополнительных расширений и доработок.
Собственно, когда вылетает платформа по непонятным причинам или например "Аварийное завершение работы базы". Или
Ошибка при вызове метода контекста (ПрочитатьИзменения): Данные принимаются от узла с другим набором расширений, меняющих структуру данных.
Необходимо произвести перенос расширений конфигурации в узел.
Это прежде всего связано с недоработкой платформы и взаимодействием её с памятью. В подробности вникать ни к чему, так как всем нужен результат, но проблема явно остается платформенная и пока не доработана разработчиками.
Если реально присутствуют расширения, то делаем так:
1. Делаем всё на копии основной базы
3. Сохраняем все расширения путем выгрузки в файл. а затем Удаляем проблемные расширения, если нет понимания какое именно - удаляйте все.
4. Заходим в режим предприятия и делаем создание первоначального образа РИБа. Образ с вероятностью 99% должен будет создаться. (1% если конфигурация сломана, её следует вернуть на оригинальную)
4.1. Заходим в конфигуратор и загружаем DT из п.2
5. Далее заходим в созданный РИБ и отвязываем его от главного узла с помощью прикрепленной обработки.
6. Заходим в конфигуратор, Устанавливаем все расширения из п.3, обновляем конфигурацию БД РИБа
7. Заходим в режим предприятия РИБа - привязываем его к центральному узлу (все таже обработка)
8. Делаем синхронизацию в обеих базах. Будут ошибки - смотрим читаем журнал. Перезаходим в РИБ.
9. В РИБе полезно нажимать на кнопку "Выполнить сценарий". Конфигуратор должен быть в это время закрыт. Иначе будет ошибка блокировки смотреть в журнале.
После нескольких попыток базы должны будут синхронизироваться и все расширения должны привязаться от главного узла.
В 1С может появиться ошибка такого рода: Ошибка при чтении изменений при обмене РИБ: Ошибка при вызове метода контекста (ПрочитатьИзменения): Попытка вставки неуникального значения в уникальный индекс:
Microsoft SQL Server Native Client 11.0: Не удается вставить повторяющуюся строку ключа в объект «dbo._AccRgAT118760» с уникальным индексом «_AccR118760_ByPeriod_TRRRRN». Повторяющееся значение ключа: (ноя 1 5999 12:00AM, 0xab52f3e52b35efa847b0cfef9c90ff9d, 0x95eb00112f2a1abf11dac09f12116a47, NULL, NULL, NULL, NULL, 0).
HRESULT=80040E2F, SQLSrvr: SQLSTATE=23000, state=1, Severity=E, native=2601, line=1
Техническая информация:
Ошибка при чтении изменений при обмене РИБ: : Ошибка при вызове метода контекста (ПрочитатьИзменения): Попытка вставки неуникального значения в уникальный индекс:
Для ее решения делаем следующее:
1. Переходим на сервер SQL и запускаем SQL Server Management Studio
2. Находим сбойную базу в списке баз.
3. Нажимаем ПКМ и выбираем «Создать запрос»
4. В окне запроса пишем код для поиска данных в таблице:
- _AccRgAT118760 – название таблице в котором произошел сбой. Оно отображается в окне ошибки в 1С.
- _AccountRRef – название столбца_1 где будем искать.
- 0xab52f3e52b35efa847b0cfef9c90ff9d – значение_1 которое будем искать. Оно отображается в окне ошибки в 1С.
- _Fld18737RRef – название столбца_2 где будем искать.
- 0x95eb00112f2a1abf11dac09f12116a47 – значение_2 которое будем искать. Оно отображается в окне ошибки в 1С.
Название столбцов можно посмотреть следующем образом:
— Развернуть базу, нажав плюсик напротив базы
— Развернуть папку «Таблицы», нажав на плюсик напротив этой папки
— Найти в списке нашу таблицу
— Нажать ПКМ на таблицу и выбрать пункт «Выбрать первые 1000 строк»
— Появится окно с запросом и ниже окно с данными
— В запросе мы увидим название всех столбцов присутствующих в таблице. Эти названия мы можем скопировать для своего запроса.
test_stand_2_cb – название нашей сбойной базы
_AccRgAT118760 – таблица, в которой будем производить удаление объекта
_AccountRRef – столбец_1, в котором будем искать параметр для удаления
0xab52f3e52b35efa847b0cfef9c90ff9d – значение_1, которое должно стоять в столбце_1
_Fld18737RRef – столбец_2, в котором будем искать параметр для удаления
0x95eb00112f2a1abf11dac09f12116a47 – значение_2, которое должно стоять в столбце_2
_Fld18739 – столбец_3, в котором будем искать параметр для удаления
-1500.00 – сумма, которая должна стоять в столбце_3. Так как первое и второе значение будет содержаться во многих строках в таблице, нам нужно будет третье уникальное значение, по которому будет происходить поиск для удаления. Сумма нам может в этом помочь, т.к. значение суммы может совпадать с суммой сбойного документа.
- После написания запрос на удаления значения из таблицы нажимаем кнопку «Выполнить» или F5 на клавиатуре.
- После выполнения процедуры в SQL мы можем произвести нужные нами манипуляции со сбойным документом, которые ранее выдавали нам ошибку.
- Так же крайне желательно произвести пересчет итогов и проверить обороты.
Related Posts
12 Comments
Очень бы хотелось узнать, по какой причине возможно такое? Что такое смогли сделать пользователи, что 1С вываливается в такую ошибку.
А еще можно просто отключить использование итогов, выполнить обмен и включить использование итогов обратно… Индекс полностью пересоздастся (AccRg — это таблица регистра бухгалтерского, если ничего не путаю) и все будет хорошо.
(1)Обычно такого рода ошибка появляется (у нас) при изменении структуры счета: например признака «суммовой» по одному из субконто, или что-то подобное… Но не каждый раз. Предполагаю, что это как-то связанно с тем в каком порядке в фале обмена идет информация об изменении — видимо бывает так, что сначала пытаются загрузится движения, а потом — изменения плана счетов. Тогда пересчет существующих движений еще не произошел и вставка новых движений (и их индексация) конфликтует с ними… Ну сугубо мои домыслы — глубокий анализ не проводил…
В нашем случае произошел сбой в SQL, повредился один из авансовых отчетов. Что ты с ним не делай, появлялась такая ошибка. В пример я скопировал ошибку из обмена, в котором были изменения для этого документа. По факту получилось что вовремя сбоя происходили манипуляции с документом и проводки по нему записались частично. Повторно записать или удалить проводки при помощи 1С не получалось, всегда появлялась ошибка «Не удается вставить повторяющуюся строку ключа в объект». Перепробовав все что можно помог только этот способ с нахождением битых данных и удаление их через SQL.
Я не утверждаю что это золотой грааль решения данной проблемы, но данный способ нам помог и я решил им поделиться. SQL-я боятся не надо и если все делать грамотно и аккуратно, то ни чего не сломаешь.
(6) Как говорил один знакомый электрик, люди боятся электричества в двух случаях: когда не знают, как это работает и когда ТОЧНО знают, как это работает. А не боятся — когда ДУМАЮТ, что знают… С SQL — тоже самое. И ваш случай, к сожалению, последний.
AccRgAT — таблица ИТОГОВ по счету.
_AccountRRef — Ссылка на счет.
_Fld18737RRef — согласно документации — измерение или ресурс… Предположу ,что в вашем случае — измерение, и думаю, что это — Организация.
-1500 — Собственно итог.
Что выделаете? Вы удаляете запись из таблицы итогов. Напрямую из таблицы. По какому-то счету. После чего у вас все проводится и вы думаете, что исправили ошибку.
После этого вы итоге не пересчитываете, а счастливо продолжаете жить дальше…
Хотите совет? 😉 Пересчитайте итоги. Бухгалтерские. Полностью. Можно еще построить оборотку по предположительно проблемным счетам — до и после этой операции. И сравнить. Возможно удивитесь.
Итоги после этого пересчитали и оборотку формировали, все норм.
Могу да же больше сказать, эта проблема возникла в последний день сдачи отчетности и проблему надо было решать оперативно. Отчетность сдана успешна.
(8) Хорошо! Если пересчитали итоги — то в принципе ничего страшного не произошло… Неплохо бы написать об этом в статью 13 пунктом…. 😉
Читайте также: