Запись изменений текущей информационной базы в файл обмена завершилась с ошибками
Распределенная информационная база (РИБ) достаточно часто используется для организации работы филиалов и подразделений, позволяя оперативно обмениваться информацией, сохраняя нужную степень автономности. Несмотря на то, что данная технология достаточно надежна, время от времени ломается и она. Сегодня мы рассмотрим одну из довольно распространенных ошибок: Конфигурация узла распределенной ИБ не соответствует ожидаемой! Расскажем о причинах ее возникновения и методах борьбы с ней.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Начнем, как всегда, с начала. После того, как вы создали РИБ все изменения в конфигурацию информационной базы можно вносить только в главном узле. Впоследствии, при следующем обмене, все изменения будут переданы в подчиненные узлы и автоматически применены там. Но гладко было на бумаге.
В общем мораль этой истории проста - не ведите активную доработку рабочей базы, а если ведете, то завершайте все сеансы обмена до внесения следующих изменений. Но как быть, если такая неприятность все-же произошла?
Решение "в лоб" - создать новый образ подчиненного узла, однако на практике он обычно неприменим. Как правило возникновение серьезной ошибки при обмене фиксируется не сразу, а через некоторое время после того, как перестали поступать оперативные данные из периферийных баз. В зависимости от расписания обмена между моментом возникновения проблемы и ее обнаружением может пройти целый рабочий день, а то и более.
Откройте командную строку и введите (с учетом версии платформы и реального пути установки):
После выполнения данной команды появится обычное окно стартера, выберите там нужную базу и нажмите кнопку Конифгуратор.
Внимание! На платформах 8.3.7 - 8.3.9 выполнение данной команды приводит к аварийному завершению работы. Ошибка исправлена в платформе 8.3.10.
Если вы не хотите возиться с командной строкой, то можно воспользоваться одной из обработок, ниже представлена та, которую используем мы, она была найдена на просторах сети, и мы внесли в нее лишь косметические правки. Обратите внимание, обработка подходит лишь для обычного приложения, для конфигураций на управляемом приложении используйте ключ запуска Конфигуратора.
Работа с ней предельно проста, запускаем ее в режиме 1С:Предприятия, через Файл - Открыть, затем просто нажимаем нужную кнопку, в нашем случае Отключить главный узел.
Теперь нам потребуется актуальная конфигурация из центрального узла. Для этого откроем центральную ИБ в Конфигураторе и выполним Конфигурация - Сохранить конфигурацию в файл. Полученный файл с расширением cf потребуется передать в периферийный узел.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Спецы, кто устраивал обмен в РБД ч-з FTP? (8.1)
Первый обмен происходит без ошибок, потом 1С выдает ошибку:
Начат обмен данными по настройке "Обмен с ЦО" (12:08:05).
Возможно дата файлов обмена не превосходит дату последнего файла обмена данными через FTP: 24.08.2011 11:04:49
Не найден входящий файл обмена данными.
Запись изменений текущей информационной базы в файл обмена завершилась успешно.
Обмен данными по настройке "Обмен с ЦО" завершен (12:08:07).
Т.е., 1С считывает старый файл, якобы лежащий на FTP, захожу на FTP браузером, файл новый, и время у него не то, что указано в ошибке, файл свеженький.
Вторую неделю бьюсь, может кто поможет?
Только не надо советовать делать обмен ч-з почту, этот вариант не устраивает.
Такое бывало с некоторыми FTP-серверами. Однажды расхождение даты шло аж на год. При чем происходило это иногда и причину так и не удалось выяснить.
А вообще при работе с FTP дополнительно запускали сервис переноса файлов в сетевую папку, а сам обмен уже настраивали на нее. Это сразу "закрыло" многие вопросы транспортировки файла и избавило от необходимости перезакачивать файл в случае сбоя во время обмена (типовой механизм не проверяет, что файл уже был скачан).
"Денис, спасибо большое, что отреагировали.
Ч-з 3 часа после того, как я написал вопрос на форуме, сам нашел причину и решение
Могу поделиться.
Это было написано в Общем модуле ПроцедурыОбменаДанными:
________________________________________________________ ___________________
ВремяИзмененияТекущегоФайла = ТекущийФайлДляОбмена.ПолучитьВремяИзменения();
//дата последнего файла обмена должна быть меньше текущего файла обмена
Если (СтруктураНастроекОбменаДанными.ДатаПоследнегоФайлаОбмена <> Неопределено)
И (СтруктураНастроекОбменаДанными.ДатаПоследнегоФайлаОбмена > ВремяИзмененияТекущегоФайла) Тогда
Продолжить;
КонецЕсли;
____________________________________________________________ _______________
Как раз ошибка и заключается в неправильной отработке метода ПолучитьВремяИзменения()
Я просто закоментарил следующие строки до КонецЕсли. В режиме файлового обмена и так проверяется дата и время выгруженного файла. А тут зачем-то решили контролировать дату и время прямо на FTP, наверное чтобы сэкономить трафик. А метод ПолучитьВремяИзменения() не всегда отрабатывает корректно на FTP-шнике ("При чем происходило это иногда и причину так и не удалось выяснить."). Нет необходимости в контроле прямо на FTP, скачали, потом анализируем содержимое, как в файловом варианте. Почему нет? ошибка исчезла. И не надо организовывать сервис переноса в сетевую папку
А вот прчина такого косяка -
В 1С действительно некоторые фунции работы с датой и временем отрабатывают не вполне корректно. Я с подобной проблемой сталкивался еще в 7.7, на сертификации мне попалась задачка, в которой использовался метод ВыбратьДокументы(). Если не указываются даты, то, якобы, выбираются все документы с самого первого, но тогда невозможно увидеть документы с пустыми строками.
Короче, экзаменатор это заметил и молча дал мне еще 4 часа, чтобы я выяснил причину. Когда я это раскопал, он мне сам сказал, что это недокументированная ошибка
Еще раз спасибо :-)"
Проблемы с обменом в РБД ч-з FTP
Спецы, кто устраивал обмен в РБД ч-з FTP? (8.1)
Первый обмен происходит без ошибок, потом 1С выдает ошибку:
Начат обмен данными по настройке "Обмен с ЦО" (12:08:05).
Возможно дата файлов обмена не превосходит дату последнего файла обмена данными через FTP: 24.08.2011 11:04:49
Не найден входящий файл обмена данными.
Запись изменений текущей информационной базы в файл обмена завершилась успешно.
Обмен данными по настройке "Обмен с ЦО" завершен (12:08:07).
Т.е., 1С считывает старый файл, якобы лежащий на FTP, захожу на FTP браузером, файл новый, и время у него не то, что указано в ошибке, файл свеженький.
Вторую неделю бьюсь, может кто поможет?
Только не надо советовать делать обмен ч-з почту, этот вариант не устраивает.
Это было написано в Общем модуле ПроцедурыОбменаДанными:
__________________________________________________ _________________________
ВремяИзмененияТекущегоФай ла = ТекущийФайлДляОбмена.Полу� �итьВремяИзменения();
//дата последнего файла обмена должна быть меньше текущего файла обмена
Если (СтруктураНастроекОбменаД� �нными.ДатаПоследнегоФайла Обмена <> Неопределено)
И (СтруктураНастроекОбменаД� �нными.ДатаПоследнегоФайла Обмена > ВремяИзмененияТекущегоФай ла) Тогда
КонецЕсли;
__________________________________________________ _________________________
Как раз ошибка и заключается в неправильной отработке метода ПолучитьВремяИзменения()
Я просто закоментарил следующие строки до КонецЕсли. В режиме файлового обмена и так проверяется дата и время выгруженного файла. А тут зачем-то решили контролировать дату и время прямо на FTP, наверное чтобы сэкономить трафик. А метод ПолучитьВремяИзменения() не всегда отрабатывает корректно на FTP-шнике ("При чем происходило это иногда и причину так и не удалось выяснить."). Нет необходимости в контроле прямо на FTP, скачали файл, потом анализируем содержимое, как в файловом варианте. Почему нет? ошибка исчезла. И не надо организовывать сервис переноса в сетевую папку :-)
---------- Post added at 19:18 ---------- Previous post was at 19:18 ----------
Это было написано в Общем модуле ПроцедурыОбменаДанными:
__________________________________________________ _________________________
ВремяИзмененияТекущегоФай ла = ТекущийФайлДляОбмена.Полу� �итьВремяИзменения();
//дата последнего файла обмена должна быть меньше текущего файла обмена
Если (СтруктураНастроекОбменаД� �нными.ДатаПоследнегоФайла Обмена <> Неопределено)
И (СтруктураНастроекОбменаД� �нными.ДатаПоследнегоФайла Обмена > ВремяИзмененияТекущегоФай ла) Тогда
КонецЕсли;
__________________________________________________ _________________________
Как раз ошибка и заключается в неправильной отработке метода ПолучитьВремяИзменения()
Я просто закоментарил следующие строки до КонецЕсли. В режиме файлового обмена и так проверяется дата и время выгруженного файла. А тут зачем-то решили контролировать дату и время прямо на FTP, наверное чтобы сэкономить трафик. А метод ПолучитьВремяИзменения() не всегда отрабатывает корректно на FTP-шнике ("При чем происходило это иногда и причину так и не удалось выяснить."). Нет необходимости в контроле прямо на FTP, скачали файл, потом анализируем содержимое, как в файловом варианте. Почему нет? ошибка исчезла. И не надо организовывать сервис переноса в сетевую папку :-)
Ситуация следующая. УТ81. Настраиваю автообмен между распределенными базами по правилу обменав режиме РИБ (задолбался вручную обменивать). . Тестирую. Выгрузил ценральную (далее CBD) и переферифную (далее MCO). Обе загрузил в тестовые скулевые базы данных. . Выгрузка из MCO настраивается по расписанию "на ура" - файл создается. Настраиваю загрузку в центральную CBD. Пробовал и по расписанию, и "При появлении файла". . При загрузке из MCO в CDB пишет: Начат автоматический обмен данными по настройке "MCO" (12:27:43). Не выбрано регламентное задание для настройки обмена. Ошибка при чтении изменений из файла обмена. Ошибка при вызове метода контекста (ПрочитатьИзменения): Операция не выполнена! Чтение данных из файла обмена завершено с ошибками! Обмен данными по настройке "MCO" завершен (12:27:48). . Самое забавное то, что файл благополучно удаляется. . Занавес. Ошибка при чтении изменений из файла обмена. Ошибка при вызове метода контекста (ПрочитатьИзменения): Операция не выполнена!
Далее - забавнее, когда пытаюсь загрузить вручную выгруженный файл обмена из MCO в CBD получаю отлуп: . Не выбрано регламентное задание для настройки обмена. . баба яга в шоке
Неужели трудно сделать глобальный поиск "Чтение данных из файла обмена завершено с ошибками" в конфигурации, поставить там точку останова и запустить отладчик? Предварительно проверив что в свойствах северной базы не стоит галка блокировка реграментных заданий.
+ - к тому же - это часть проблемы, причем - не столь важная - важнее - почему затыкается чтение файла?
Все дело в том, что я "умственно отсталый имбицилл" - вместо того, чтобы скопировать план обмена "Полный" - создал свой и разрешил обмениваться всеми справочниками и регистрами обмена, тогда как есть справочники и регистры, которые не подлежат обмену - в том числе справочники настроек обмена, выполнения обмена, регист истории обмена )))) и при попытке загрузить в центральную видимо возникает конфликт - по коду пытается перезаписать настройку котороая сейчас используется
Когда меня озадачили в файловом варианте конфигурации Управление торговлей 10.3 реализовать выполнение обмена под интерфейсом кассира - чтобы было удобно и быстро, я так и не нашел нужного мне решения. Основная проблема - права доступа у роли кассира на выполнение обмена УРБД, точнее отсутствие этих прав. Давать же полные права - это давать админские права. Создавать отдельного пользователя для выполнения обмена с полными правами - опять те же грабли с правами и лишнее усложнение процедуры обмена. Небольшие изменения в конфигурацию - и пользователь без полных прав может делать обмен данными РИБ.
В общем, другие советы шаманов также не подходили, я лишь понял, что обмен РИБ и роль пользователя несовместимы, а другие манипуляции излишни.
Выход был, как ни странно, прост – что называется граблями по граблям – путем наделения пользователя полными правами, но только на время процедуры обмена. Это делается методом глобального контекста УстановитьПривилегированныйРежим(Истина). В принципе прописывать его отключение в файловом варианте необязательно – при возврате из процедуры/функции, в которой был включен привилегированный режим, он будет выключен автоматически (неявно).
- Создан интерфейс «Обмен РИБ» с одной кнопкой «Выполнить обмен», создана роль «Обмен РИБ» - права только на запуск и право на выполнение обновлений информационной базы – это на случай если будут изменения конфигурации и кассир может через свой интерфейс обновить конфигурацию самостоятельно, но это уже другая история. И все, больше никаких админских прав.
- В модуле обычного приложения в процедуре ЗапускИнтерфейсаКассира() подключаем интерфейс «Обмен РИБ».
- В общие модуле ПараметрыОбменаДанными в процедуре ОткрытьФормуВыполненияОбменаРИБ() – для роли "ОбменРИБ" включаем привилегированный режим.
- В общие модуле ПроцедурыОбменаДанными в процедуре ВыполнитьОбменДаннымиПоПроизвольнойНастройке () – для роли "ОбменРИБ" включаем привилегированный режим.
- В общей форме ФормаВыполненияОбменаДанными в процедурах ОпределитьНаличиеНастройки() и УстановитьПараметрыОбменаПоНастройке() – для роли "ОбменРИБ" включаем привилегированный режим.
Необходимого пользователя наделяем ролью "ОбменРИБ" – и делаем обмен.
В приложении файл обновления. Как обновить: берем стандартную УТ 10.3.29.1 и обновляем - Конфигурация -> Поддержка -> Обновить конфигурацию, выбираем файл обновления - обновляем. Затем выгружаем конфигурацию в файл и этим файлом обновляем рабочую базу.
Специальные предложения
Добрый день, подскажите пож. подробнее сам процесс обновления. У меня после обновления сохраненной в файл измененной конфы 10.3.29.1 рабочей 10.3.45.2 слетает информация о версии конфигурации - теперь обновление возможно лишь с 10.3.25.1. При обновлении все галки сняты, кроме интерфейса и роли "ОбменРИБ". Как правильно обновить?
Решал задачу обмена по расписанию и при входе/выходе под обычным пользователем следующим образом (УТ 10.3.50.2, база файловая, поэтому галка "Выполнять обмен под полными правами" не отрабатывает):
1. Создал копированием роль "ПользовательДляОбменаРИБ" с роли "Пользователь";
2. В правах доступа справочников "НастройкиВыполненияОбмена" и "НастройкиОбменаДанными" для роли "ПользовательДляОбменаРИБ" для права "Чтение" удалил ограничение доступа к данным (удалена строка ограничений - ГДЕ Ложь);
3. В общем модуле "ПроцедурыОбменаДанными" в процедуре ВыполнитьОбменПоНастройкеАвтоматическогоОбмена в самом начале добавил повышение привилегий для автоматического обмена
4. Для учетной записи пользователя назначил роль "ПользовательДляОбменаРИБ" совместно с ролью "Пользователь".
По итогу - кассир работает со обычными правами, обмен идет как на входе/выходе, так и по расписанию.
что то ничего не помогает во все перечисленные модули напихал УстановитьПривилегированныйРежим(Истина); У пользователя в правах убрал " <Прочие поля>- ГДЕ Ложь" на указанные выше справочники.
Прочие>Итог все равно один
----------------
Начат обмен данными по настройке "ЦБ" (20:05:22).
Редактирование данных этого периода запрещено. Изменения не могут быть записаны.
Ошибка при чтении изменений из файла обмена.
Ошибка при вызове метода контекста (ПрочитатьИзменения): Не удалось записать "Установка цен номенклатуры УТ000000008 от 01.06.2020 12:27:55"!
Чтение данных из файла обмена завершено с ошибками!
Запись изменений текущей информационной базы в файл обмена завершилась успешно.
Обмен данными по настройке "ЦБ" завершен (20:10:11).
----------------
В истории обмена пишет:
----------------
Ошибка при вызове метода контекста (ПрочитатьИзменения): Не удалось записать "Установка цен номенклатуры УТ000000008 от 01.06.2020 12:27:55"!
Техническая информация:
: Ошибка при вызове метода контекста (ПрочитатьИзменения): Не удалось записать "Установка цен номенклатуры УТ000000008 от 01.06.2020 12:27:55"!
----------------
Я уже в этой процедуре в начале добавил УстановитьПривилегированныйРежим(Истина);
Отладчиком захожу до этой строчке 1622 в мониторе значение ПривилегированныйРежим() возвращает Истина даже после вылета по ошибке, не понимаю куда еще копнуть.
Читайте также: