Ошибка формата представления изменений 1с при обмене
Ситуация следующая. УТ81. Настраиваю автообмен между распределенными базами по правилу обменав режиме РИБ (задолбался вручную обменивать). . Тестирую. Выгрузил ценральную (далее CBD) и переферифную (далее MCO). Обе загрузил в тестовые скулевые базы данных. . Выгрузка из MCO настраивается по расписанию "на ура" - файл создается. Настраиваю загрузку в центральную CBD. Пробовал и по расписанию, и "При появлении файла". . При загрузке из MCO в CDB пишет: Начат автоматический обмен данными по настройке "MCO" (12:27:43). Не выбрано регламентное задание для настройки обмена. Ошибка при чтении изменений из файла обмена. Ошибка при вызове метода контекста (ПрочитатьИзменения): Операция не выполнена! Чтение данных из файла обмена завершено с ошибками! Обмен данными по настройке "MCO" завершен (12:27:48). . Самое забавное то, что файл благополучно удаляется. . Занавес. Ошибка при чтении изменений из файла обмена. Ошибка при вызове метода контекста (ПрочитатьИзменения): Операция не выполнена!
Далее - забавнее, когда пытаюсь загрузить вручную выгруженный файл обмена из MCO в CBD получаю отлуп: . Не выбрано регламентное задание для настройки обмена. . баба яга в шоке
Неужели трудно сделать глобальный поиск "Чтение данных из файла обмена завершено с ошибками" в конфигурации, поставить там точку останова и запустить отладчик? Предварительно проверив что в свойствах северной базы не стоит галка блокировка реграментных заданий.
+ - к тому же - это часть проблемы, причем - не столь важная - важнее - почему затыкается чтение файла?
Все дело в том, что я "умственно отсталый имбицилл" - вместо того, чтобы скопировать план обмена "Полный" - создал свой и разрешил обмениваться всеми справочниками и регистрами обмена, тогда как есть справочники и регистры, которые не подлежат обмену - в том числе справочники настроек обмена, выполнения обмена, регист истории обмена )))) и при попытке загрузить в центральную видимо возникает конфликт - по коду пытается перезаписать настройку котороая сейчас используется
Что делать с этим?
помогите!
это и сделать что оно просит - Необходимо произвести перенос изменений конфигурации в узел. У вас метаданные в узлах не идентичны. РИБД так не работает! Только для идентичных конфигураций!
(2)я на периферийных принимаю обновления, а они на 96% ошибку выдает. Обновление с перескоком через три релиза.
(5)
Выгрузите из ЦБ файл конфигурации, отвяжите удаленную базу от РИБ, загрузите в нее новую конфигурацию, при старте согласитесь на восстановление РИБ
Вы обновили центральный узел, и теперь нужно обновить дочки. без этого не будет работать обмен. Зайдите в дочке в конфигуратор, и нажмите обновить конфигурацию, на сколько я помню
(3)я пыталась обновить , но на 96% выдает ошибку. (фото в приложение), причем не пойму, почему обновление пишет редакция 2.1, если редакция в ЦБ обновлена 2.2.
Обновление ЦБ было в три этапа (три релиза)
в ручную обновить периферийные не могу, так как там закрыт доступ. Уже сил нет ни каких.
(10) (11) а если вернуть старый релиз в ЦБ и заново по одному релизу? потеряются данные? и возможно ли это в принципе
(10)
При загрузке конфигурации из ЦБ, при старте Предприятия программа сама предложит восстановить узел РИБ
(9) Можно, слышал делали так, но сам никогда не делал. Ну и кто знает получится ли такую обновить и потом обратно сделать дочкой.
(11) Периферийный узел сделать центральным - можно. Наоборот насколько я помню фигушки.
(12) Попробуйте на копии и прогоните обмен из нее. Но похоже вы налипли на отпочковывание периферий заново. Сочуствую вашему геморрою.
Я бы даже сделал по копии для ЦУ и периферийной баз и на этом стенде уже поковырялся. Но сомнения меня гложут. Давно не работал с РИБД и слава богу!
(14)
Центральный нельзя сделать переферийным? Вы шутите, ведь так и создавался образ первоначальный узла
(7) бекап необновленной ЦБ есть? Поднимите ее как копию, и по одному пакету обновлений ставьте в не (воспроизводите все действия) и выгружайте в подчинённые, как сровняете продолжайте с основной обмен. Ток в копии центральной отмените регистрацию всех данных.
(38) А что, так можно было? ) я то мучал раньше, шаг за шагом центр - риб, т.е. он все последовательно обработчки позапускает которые были, независимо от кол-ва пройденных релизов?
(39)
Можно,
Последовательность действий:
выгружаем из ЦБ cf-файл;
отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню «Загрузить конфигурацию из файла» (а не сравнением-объединением. );
восстанавливем признак РИБ для УБ.
Такая же проблема, через конфигуратор обновляется, дальше зависает, решается n-м количеством повторений, иногда со второго раза иногда с пятого, но всё проходит.
(19)у меня попыток с 10 было когда сразу через несколько релизов , теперь только по одному релизу сначала центральная база, затем все точки, потом только следующий релиз, главное сразу после синхронизации зайти в конфигуратор там обновить, а потом уже в предприятие зайти.
(18)
Это когда не все обработки обновления были завершены в ЦБ при обновлении ее до выгрузки в файл обмена
При ошибках при обновлении периферийных баз делали так: выгружали с центральной базы cfник, в периферийной выполняли команду
После этого перезапускали конфигуратор и загружали cfник из центральной базы через Конфигурация->Загрузить конфигурацию из файла. Именно загрузить. Сравнение/объединение не пойдет.
После обновления конфы запускаем режим предприятия и выполняем команду
где ГлавныйУзел соответствует главному узлу из плана обмена РИБ
После этого проводим синхронизацию с центральной базой в обычном режиме. Чаще всего эти действия приводили к восстановлению синхонизации.
(36)Я ничего не поняла)) для меня сложно понять куда это все прописывать. Я в 1С новичок. Я сделала в итоге так: их ЦБ создала начальный образ нужного мне магазина , загрузила в Яндекс Диск. Далее зашла в перефирийный комп, нашла путь где лежит 1С , поменяла старый образ на новый (который на яндекс диск). Окрыла 1С перефирийный, он синхронизировался с главным компом, получил обновления и все. На перефирийном стоит уже последний релиз, синхронизация успешно настроена. Не знаю на сколько мои действия были верны. мне так подсказали. Можно ли это считать корректным действием?
(41)
Таким образом вы потеряли всё, что было занесено на узле с момента последней синхронизации, если такой вариант подходит, практику можно считать успешной
(42)не совсем понятно что именно утеряно. Начальный образ нужного магазина выгружала весь из ЦБ (около 2-х часов заняло), когда загруженный файл меняла один на другой на периферийном то после синхронизации с ЦБ вся база 1С периферийного осталась такой же какой до данной переустановки. Изменилось лишь то, что релиз стал последним. Объясните пожалуйста что именно потеряно
(43)
То, что было занесено (данные) в узле за время от последнего удачного обмена при синхронизации и до этого момента, когда вы выгрузили образ узла из ЦБ, что тут не понятно?
(44)периферийный не работал все это время, так что терять там было нечего. \и что хамить то))) Вы родились со знаниями всех премудростей 1С? Спасибо за ответ, всего доброго!)
(45)
Во-первых вам никто не хамил, никто не виноват, что с первого раза не понимаете, во-вторых, "второй не работал все это время", значит и предыдущей передачи не было, вывод данные все же какие-то потеряны", и пожалста
После установки новой платформы 1с 8.3.11.2924 при обмене с узлами РИБ возникла ошибка. Ошибка при чтении изменений при обмене РИБ: Ошибка при вызове метода контекста (ПрочитатьИзменения): Данные принимаются от узла с другим набором расширений, меняющих структуру данных.
Итак возникла проблема . Установили на центральном узле РИБ новую платформу версия 8.3.11.2924. Работает на ней конфигурация Комплексная автоматизация 1.1 в режиме совместимости с версией 8.2.13. Кроме этого на этом же сервере 1с расположены и другие базы, для которых новая платформа и нужна. В узлах РИБ платформа пока не обновилась. И при выполнении обмена получили ошибку:
" Ошибка при чтении изменений при обмене РИБ: Ошибка при вызове метода контекста (ПрочитатьИзменения): Данные принимаются от узла с другим набором расширений, меняющих структуру данных.
Необходимо произвести перенос расширений конфигурации в узел."
Никаких расширений в режиме совместимости с 8.2.13 в конфигурации речи быть не может, но факт есть факт. Причем в узлах где платформу пока не поменяли, никаких ошибок не возникло.
Сравнив файлы обмена приходящие из узлов на старой и новой платформах выяснилось, что разница идет в одном атрибуте, а именно
Добавил этот атрибут в файл обмена, ошибки при приеме нет.
Обработка в приложении берет указанный zip файл, распаковывает файл обмена, находит узел v8de:Digest2, и добавляет атрибут Extensions="0000000000000000000000000000000000000000", после чего запаковывает обратно в zip, и удаляет временный файл.
Пароль при распаковке, упаковке не использую.
Естественно, что это только временная мера, пока все узлы РИБ не перейдут на новую версию платформы, или 1с не научит платформу обмену в режиме совместимости.
1. Конфигурация узла распределенной ИБ не соответствует ожидаемой.
Самой распространенной ошибкой при использовании распределенных баз в 1с:Предприятие 8.x является ошибка "Конфигурация узла распределенной ИБ не соответствует ожидаемой". Связана она с рассинхронизацией конфигурации главного и подчиненного узла, возникать может по нескольким причинам, самая распространенная из них это динамическое обновление конфигурации. Рассмотрим основные пути решения данной проблемы, укажу способы по простоте их использования, сначала самые простые (но иногда не менее эффективные), потом более сложные:
Чистка кэша .
- При работе в режиме предприятия 1с кэширует метаданные для ускорения работы программы и при динамическом обновлении конфигурации использует их до момента перезапуска сеанса пользователя. При это могут возникать ситуации, когда после перезапуска программа не обновила метаданные из измененной, а продолжает использовать старые. В такой ситуации помогает очистка кэша, при новом запуске программа обновит метаданные. Очистить кэш можно множеством способов, приведу несколько из них:
- На мой взгляд самый простой из них это удаление базы из списка информационных баз и добавление заново под другим именем. При добавлении базы как новой в список информационных баз программа создаст новый каталог на диски для хранения кэшей к этой базе.
- Можно очистить базу удалив папки с кэшем. Папки храняться в зависимости от версии windows:
\Local Settings\Application Data\1C\1Cv82
Можно воспользоваться готовым bat-файлом для удаление файлов кэша, как это описано в этой статье "Чистка кэша 1с".
Не денамическое обновление корневого узла.
- Данный метод обноружил случайно, на просторах интернета такого способа не нашел, но помогает он очень часто и в отличии от следующих способов помогает решить проблему намного быстрее и проще. Заключается он в том, что мы еще раз меняем что либо в корне конфигурации (я чаще всего меняю синоним конфигурации, например добаляя пробел в конце синонима) и делаем при этом не динамическое обновление. После этого производим еще раз обмен из главного узла с подчиненными. В большенстве случаев, хотя и не всегда к сожалению, данный метод позволяет решить ошибку рассинхронизации конфигураций. Этот способ не всегда является эффективным, но в отличии от следующих способов позволяет быстро решить данную проблему, особенно при большом количестве узлов распределенных баз.
Перенос конфигурации в распределенный узел .
Самый распространенный способ решения данной проблемы, он почти в 100% случаев помогает решить данную проблему, опять таки замечу, что почти в 100%, т.к. у меня возникали случаи, когда переносом конфигурации из главного узла в подчиненный проблема не решалась. Данный метод заключается в переносе конфигурации из главной базы в распределенную.
Последовательность действий:
- выгружаем из центральной базы конфигурацию в cf-файл;
- отвязываем переферийную базу от главного узла, вызвав команду:
- заменяем конфигурацию переферийной базы на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла".
- Привязываем переферийную базу обратно к главному узлу РИБ, вызвав команду:
где в качестве параметра передаем главный узел распределенной базы.
Для выполнение этих действий удобнее всего воспользоваться обработкой, которую можно скачать здесь (подходит для всех конфигураций на не управляемых формах, т.к. Розница 1.0 или УТ 10.3, огромное множество аналогичных можно найти на просторах инфостарта).
Подмена хэша конфигурации в файле обмена.
- Данный метод был взят из статьи Популярные ошибки РИБ. Метод на мой взгляд довольно таки сложный и длительный, поэтому я его указываю как самый последний из вариантов решения данной проблемы, его стоит использовать только лишь в том случае, если не один из выше перечисленных способов не позволил решить проблему. Его суть заключается в том, что мы заменяем хеш конфигурации в файле обмена на правильный и тем самым обманывая программу производим обмен.
Последовательность действий:
- выполняем действия из предыдущей методики;
- выгружаем из переферийной базы файл обмена, но не загружаем его в главную базу;
- выгружаем из главной базы файл обмена, но не загружаем его в переферийную базу;
- в файле обмена из главной базы заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла переферийной базы (пример см. ниже).
- производим загрузку файла из 4-го пункта в переферийную базу;
- обязательно перезаписываем файл обмена из переферийной базы (2-й пункт) этот файл не должен быть загружен при обмене в главную базу.
- для проверки делаем несколько последовательных обменов.
Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.
Блок файла обмена из главной базы:
нужно заменить на блок файла обмена из переферийной базы (обратите внимание Digest1 у файла из переферийной базы всегда равен "00000000000000000000000000000000". )
3. Ошибка преобразования данных XML.
Lion heart
Правша
BVG
Есть сервер под управлением Windows Server 2003 с установленной 1с 8.1 Торговля
Клиенты подключаються в терминальном режиме. На двух клиентских компах установлены сканеры штрих-кодов, но в 1с работает только один из сканеров, на том клиенте который подключается первым.
порт подключается нормально, через гипертерминал на сервере оба сканера работают. в чем может быть загвоздка?
Черный запрос
Подскажите пожалуйста.
Надо заархивировать 1С-ные базы. Как это лучше сделать?
Можно несколькими способами:
1) Помещаете папки, где лежат базы, в архив. К примеру WinRar'ом;
2) Можно через конфигуратор, запускаете конфигуратор, выбираете в меню Администрироване\Сохранить данные или Выгрузить данные, указываете путь и имя файла архива Zip куда будет сохранена база. Для каждой базы делаете отдельно.
1) Можно через конфигуратор, запускаете конфигуратор, выбираете в меню Администрироване\Выгрузить данные (Сохранить данные не выбирать. ), указываете путь и имя файла архива Zip куда будет сохранена база. Для каждой базы делаете отдельно.
2) Сделать бэкап средствами SQL, Enterprise Manager'ом и помещаете файл бэкапа и папку с метаданными в архив, к примеру WinRar'ом.
Правша
Черный запрос, спасибо. Были бы базы SQL, тогда вопросов не возникло бы. А вот с простыми чет не уверен был, теперь понятно.
Еще раз спасибо
Вини
Lion heart
Lion heart
Блин, вот же засада. Неужели никто не знает ответа?
Самое интересное, если вручную делать выгрузку, то все работает, если автоматом - нет.
Lion heart
Вдогонку и по той же теме. Кто-нибудь юзал метод УстановитьГлавныйУзел() на главном узле? Что произойдет?
Lion heart
Черный запрос
Снимаю свой вопрос, разобрался сам. Никому не спасибо за невнимание.
Lion heart
Ну в общем, ничего нового я не придумывал. Когда настраивал распределенку, взял пример из Митичкина (по-моему). Прикол был в том, что этот пример формирует файл обмена не так как встроенные средства 1С. Поэтому-то когда автоматически выгруженный файл пытались загрузить вручную и выдавалась ошибка. После этого я пересмотрел немного реализацию автообмена и решил юзать обычные методы ЗагрузитьИзменения и ПрочитатьИзменения.
Щас у меня новая трабла (стыдно за себя даже).
Пока настраивал заново распределнку, поднял одну мелкую базу, чтобы обкатать автообмен. Ну, вроде, все нормально работает. Но есть одно "но". Я там использовал после метода ЗагрузитьИзменения еще один: ЗарегистрироватьИзменения. Оказывается, после этого метода, идет полная выгрузка всей имеющейся в базе информации. Ну а я этого благополучно не заметил, так как в пустых базах ессесно инфы практически ноль. Ну и загрузил эти изменения в модуле в рабочую базу. И сделал обмен. Потом обнаружил траблу и убрал метод ЗарегистрироватьИзменения. Только было поздно.
Результат: с периферии в главную изменения не проходят, так как изменения с главной еще не отражены в периферии. А выгрузка из главной в периферию отражает все данные из главной, а весят они немало. Трабла у меня щас в том, что при формировании файла обмена вываливается ошибка с недопустимым символом XML и отслеживать, где именно споткнулась выгрузка крайне трудно. Вот такие пироги.
Lion heart
Читайте также: