1с объект этой информационной базы был заменен версией объекта из второй информационной базы
У вас вдруг при входе в базу 1С:Бухгалтерия 8.3 (редакция 3.0) появился вопрос "Информационная база была перемещена или восстановлена из резервной копии?"
Что же это значит?
Это означает, что программа 1С определила, что файл с базой перемещён по другому пути, возможно даже на другой компьютер в сети.
И она у нас интересуется: экземпляр базы, который мы сейчас открыли - он основной . или это просто резервная копия или база для тестов, скопированная с основной?
Как 1с определила, что база перемещена?
Внутри каждой файловой базы находится файл DoNotCopy.txt, который при резервном копировании не попадает в архив. Поэтому если вы восстановили базу, то там этого файла просто нет. А это один из признаков, что открывается копия, а не основная база.
Есть ещё ряд признаков (в том числе для серверных баз), при помощи которых программа определяет перемещение базы.
Зачем это нужно?
Давайте для примера представим, что в нашей базе настроена синхронизация с другой (центральной). И все изменения, которые мы в ней делаем, тут же улетают (синхронизируются) в центральную базу.
Синхронизация происходит автоматически по расписанию при помощи регламентных заданий.
И вот однажды нам понадобилось потренироваться и мы скопировали основную базу в другую папку и начали в ней вводить учебные примеры, совсем забыв про синхронизацию с центральной базой.
И все эти документы ошибочно улетели в центральную базу
Чтобы избежать подобной ситуации и был введён этот механизм.
Что отвечать и к чему это приведёт?
Если мы ответим "Информационная база перемещена", то 1С посчитает эту базу основной и ничего предпринимать не будет.
Если же мы ответим "Это копия информационной базы", то 1С пометит для себя эту базу как копию и тут же отключит ряд регламентных заданий, связанных с синхронизацией данных, отправкой почты и некоторые другие, которые могут наломать дров, если будут запущены не в основной базе данных (см. пример выше).
Для 1С бухгалтерии такими регламентными заданиями (которые автоматически отключаются, если мы ответили "Это копия информационной базы) являются:
- Обмен с контролирующими органами.
- Обработка заявлений абонента.
- Отправка и получение данных ГИСМ.
- Очистка ненужных файлов.
- Сбор и отправка статистики.
- Синхронизация данных.
- Синхронизация файлов с облачным сервисом.
- Удаление неактуальной информации синхронизации.
- Экспорт оценки производительности.
Если вопрос возник для базы, которую мы считаем нашей основной (рабочей), то отвечаем "Информационная база перемещена".
Если же это просто резервная копия, восстановленная нами для тестов, учебных целей или просто посмотреть, как оно было на 1 квартал того года, тогда отвечаем "Это копия информационной базы".
Если мы ошиблись в ответе
Вариант первый
Но что делать, если мы ошиблись в ответе (поторопились) и случайно ответили "Это копия информационной базы". Как сделать копию базы снова основной (чтобы разблокировались автоматически заблокированные при нашем ответе регламентные задания)?
Для этого заходим в раздел "Администрирование" пункт "Поддержка и обслуживание":
В открывшемся окне находим раздел "Регламентные операции" и нажимаем кнопку "Разблокировать работу с внешними ресурсами":
Вариант второй
Если же мы случайно ответили "Информационная база перемещена", хотя на самом деле это копия и все регламентные задания по синхронизации должны быть заблокированы, то сделаем следующее:
2. Удалим (или просто переименуем в DoNotCopy_.txt) файл DoNotCopy.txt из папки с базой.
3. Изменим имя папки, в которой хранится база.
4. Подключим базу в список 1с и запустим её.
5. Снова возникнет вопрос, на этот раз ответим "Это копия информационной базы".
С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.
Прошу помощи в лечении обменов (двухсторонние, прямое подключение) между УТ 11.0.7.21 и БП 2.0.34.7.
После обновления конфигов 1С до последних релизов перестали ходить обмены.
Причем если начинать автообмен из БП, то обмен проходит нормально, но если производить обмен из УТ, загрузка данных не происходит, в журнале ошибка - указанный файл правил обмена не существует.
Правила обмена НЕ типовые, правил сам, переносится ТОЛЬКО номенклатура из одной базы УТ в три базы БП.
Опытным путем было выяснено, что в предпоследнем релизе конфига (11.0.7.19) все еще работает, но откатить на него не знаю как.
Правила обмена точно рабочие, поскольку обмен через локальный каталог, интерактивный обмен- все работает.
обнови бухгалтерию до 34.11. и попробуй таки использовать правила обмена стандартные. может в этом собака зарыта. помню в БП 33.8 вообще не получалось выгрузить документы и справочники. а после обновления все пошло на ура. столько тогда перекопал по поводу обмена, а решение проблемы как обычно оказалось простым и лежало на поверхности.
у меня подобная проблема.
обновились УТ до 11.0.7.21 БП до 2.0.34.11
обмен не идет.
в правилах конвертации БП написано:
в правилах конвертации УТ написано:
получается, что 1С не сделали правила для этих конфигураций! Скачал обновление БП 2.0.34.13. там те же правила, что и в 34.11
откатил БП до 33.8 Создал новый обмен, сопоставил объекты. начал выгрузку. шла часов 15. в результате документы выгрузились, хотя в журнале событий обмена куча ошибок:
вот теперь думаю, нужно ли так оставлять или искать другие пути??
Может у кого-нибудь есть правила конвертации\регистрации для этих конфигураций?
Собственно говоря у Вас контактная информация не перегружается. Так ли она нужна?? Если да, я бы отдельно в Вашем случае написал правила обмена да и все, максимум полдня займет с отладкой и всем прочим. Либо перегрузить сейчас как есть, а потом дождаться новых правил и притянуть контактную информацию
Любите ли Вы динамическое обновление конфигураций так, как люблю его я? Обожаю что-нибудь с его помощью пропатчить на продакшене! Особенно в пятницу! Вечером! Перед майскими праздниками! Без предупреждения!
На самом деле нет! Динамическое обновление с одной стороны выглядит отличным механизмом платформы 1С, который позволяет вносить изменения в конфигурации "на лету". Главное, чтобы изменения не затрагивали структуру базы данных, в противном случае придется выполнять обновление монопольно и "выгонять" пользователей.
Согласитесь, при появлении ошибки в коде после очередных изменений просто берешь и обновляешь базу "на горячую" и никаких проблем! Главное всем, кому нужны были эти изменения, перезапустили сеанс и изменения вступят в силу!
С другой стороны может что-то пойти не так и Вы найдете небольшую, но весомую порцию багов у себя.
И никакие отговорки, что это были изменения для ТОП-менеджеров Вам не помогут!
Но как же так! Вы пользуетесь динамическим обновлением и у Вас нет никаких проблем? Коллеги рассказывают страшные истории, но Вы им не верите? "Просто они плохие 1Сники!", думаете Вы?
Как работает динамическое обновление
Наверное это странный вопрос, ведь ответ лежит на поверхности - это механизм позволяет обновить конфигурацию базы данных без остановки ее работы, внося изменения не требующие модификации на уровне базы данных. В официальной документации на ИТС есть информация в каких случаях платформа позволяет провести динамическое обновление. Вроде все просто. Но что если пойти дальше.
В любой информационной базе есть таблицы "Config" и "ConfigSave". Назначение этих таблиц также известно:
- Config - содержит основную конфигурацию информационной базы, которая соответствует актуальной структуре базы данных и используется активными сеансами.
- ConfigSave - содержит сохраненную конфигурацию. Ту самую, которую Вы редактируете в конфигураторе. Как только Вы нажимаете "Сохранить", все измененные объекты и связанная информация записывается именно сюда. После запуска обновления информационной базы все изменения из этой таблицы переносятся в таблицу Config. Если же выполнить команду "Конфигурация -> Конфигурация базы данных -> Вернуться к конфигурации БД", то вся информация об изменениях в этой таблице удалится.
Все просто, не так ли? Но пойдем еще дальше. Посмотрите на структуру таблиц для хранения данных конфигурации.
Структура таблиц идентична.
Описание полей такое:
- FileName - строка длиной 128, используется для хранения имени "файла", это некоторая часть конфигурации.
- Creation - дата создания записи.
- Modified - дата модификации записи.
- Attributes - целое число, назначение которого сейчас нет смысла рассматривать (на самом деле я точно не могу утверждать, только предполагаю зачем оно нужно. Но если Вы знаете, то напишите в комментариях).
- DataSize - размер данных в байтах, хранящийся в поле "BinaryData"
- BinaryData - непосредственно данные конфигурации.
- PartNo - номер части. Иногда размер данных объекта метаданных может быть очень большим и платформа его разбивает на части.
То есть конфигурация хранится некоторыми блоками. Вообще, структура хранения конфигурации в таблице базы соответствует тому, как устроена внутренняя структура форматом файлов CF. Подробнее об этом Вы можете узнать в отличной статье "Описание формата файлов конфигурации (CF, EPF, ERF)" от Андрея Овсянкина.
Со структурой таблиц и их назначением понятно. Пойдем дальше.
Когда Вы начинаете процесс обновления информационной базы, на первом этапе платформа 1С выполняет множество служебных действий, останавливаться на которых сейчас особо нет смысла. Самое интересное начинается после того, как Вы нажимаете заветную кнопку "Обновить динамически".
Среди множества служебных действий, платформа переносит данные об объектах из таблицы ConfigSave в Config:
В следующий раз, когда информационная база будет обновляться в обычном режиме, записи об объектам, созданных при динамическом обновлении, будут удалены и останутся только основные записи с актуальными данными конфигурации.
Это очень поверхностное описание и сам процесс имеет множество особенностей как со стороны работы БД, так и со стороны работы клиентских приложений платформы 1С. Но суть должна быть понятной.
Подробный пример динамического обновления
Для того, чтобы детальней погрузиться в происходящее при таком обновлении, рассмотрим все действия платформы 1С, до которых можно добраться законым способом. То есть мы не будем влазить в модули работы самой платформы и открывать то, за что можно получить повестку в суд. Мы лишь посмотрим что делает платформа на стороне базы данных. И этого нам будет достаточно!
В нашем примере есть некоторая конфигурация на базе БСП (хотя это и не важно), в которой добавлен очень важный общий модуль "ДляДинамическогоОбновления".
Модуль полностью клиентский, имеет в своем составе только одну функцию.
На первом шаге мы вносим изменения в модуль и нажимаем "Сохранить конфигурацию". При этом изменения в конфигурации сохранены, но не применены к информационной базе.
На этом шаге платформа 1С делает записи в таблицу "ConfigSave", некоторое промежуточное хранилище, из котого потом измененные элементы конфигурации должны будут перенесены в основную таблицу конфигурации "Config".
Вот вся история операций в таблице "ConfigSave" после сохранения конфигурации. Здесь подробная информация обо всех действия практически на физическом уровне, поэтому некоторые операции "INSERT" разделены на две (INSERT и UPDATE), а операция UPDATE может быть выделена как операции DELETE и INSERT. Но эти особенности сейчас не играют роли.
Кроме этого в таблице есть дата операции (Period) и идентификатор транзакции (__$start_lsn). По факту все эти действия выполняются в разных транзакциях, лишь некоторые из действий в таблице выполняются в единой транзакции.
Вся операция, как уже упоминалось выше, делится на два этапа:
- Записываем в таблицу информацию об изменениях конфигурации , в частности нашего общего модуля "ДляДинамическогоОбновления". Кстати, на скрине выше видно, что его идентификатор "cb327a01-e9cc-44e6-af31-5f30c88faeca", отсюда и эти названия похожие. Имена содержат суффикс "new", что говорит о промежуточной записи объектов.
- На следующем шаге промежуточные записи преобразовываем в нормальные , просто исключив "new" из имен элементов конфигурации.
Тут все достаточно просто, идем к следующему шагу. Вы нажимаете кнопку "Обновить информационную базу", но так как в базе есть сеансы, а изменения касаются только модулей, то платформа 1С предлагает выполнить динамическое обновление без завершения сеансов.
В этот момент платформа 1С сделала два действия:
- Скопировала записи из таблицы "ConfigSave" в таблицу "Config" с суффиксом "new", почти все действия выполнены в одной транзакции.
- Затем было обнаружено, что обновление невозможно продолжить из-за наличия активных сеансов. Был показан диалог для динамического обновления, а ранее добавленные записи удалены из таблицы "Config" в одной транзакции.
Изменений в таблице "ConfigSave" в этот момент не выполнялось.
И вот мы добрались до последнего шага - запуска динамического обновления. Соглашаемся с этой операцией и получаем следующее.
- В таблице "Config" сначала добавляются новые записи с суффиком "new" для последующих операций с ними. Примерно такие же действия мы видели в самом начале в таблице "Config", перед тем как было предложено выполнение динамического обновления. Но в этот раз также сделаны служебные записи "commit", "dynamicCommit" и "dbStruFinal", которые относятся непосредственно к динамическому обновлению (частично о них было упомянуто выше).
- Предварительные записи с суффиксом "new" теперь платформа преобразовывает в нормальные записи, также добавляет записи с форматом "_dynupdate_", плюс вставляет флаг динамического обновления "DynamicallyUpdated".
- Из таблицы "ConfigSave" удалены все сохраненные ранее записи. Все в одной транзакции.
- И напоследок из таблицы "Config" удаляются служебные данные "commit", "dynamicCommit" и "dbStruFinal".
Заметьте, каждый этап - почти всегда разные транзакции, это важно.
После этого конфигурация успешно обновлена динамически, база работает. Чтобы клиентам получить новые изменения достаточно перезапустить сеанс. Вроде все хорошо.
На самом деле это не все действия платформы 1С, т.к. еще обновляются данные в таблице "Params" и некоторые другие. Но мы это рассматривать сейчас не будем.
Разработчики ликуют и со словами "Я же говорил" продолжают убеждать коллег, что динамическое обновление это нормально!
Что может пойти не так
Весь процесс динамического обновления мы рассмотрели, но что же может случиться?
Представим простую ситуацию: что, если все обновление прошло успешно, кроме последнего этапа? Например, во время выполнения запросов на удаление служебных данных соединение с базой данных почему-то "отпало":
- Сбой сети.
- Регламентные работы на сервере, внезапно.
- Обслуживание базы, которое завершило блокирующий сеанс, опять же внезапно!
- Конфигуратор вылетел из-за ошибки внутренней.
- Разработчик 1С был странным и завершил сеанс конфигуратора во время обновления.
- И еще сотни причин, которые лень добавлять.
Чтобы такое проще было представить, можно добавить в базу данных триггер, который при попытке удаления служебной записи о динамическом обновлении упадет в ошибку.
Попытаемся теперь выполнить динамическое обновление и столкнемся с ошибками:
- Сначала во время обновления в конфигураторе поймаем ошибку.
- А при попытке зайти в конфигуратор повторно мы словим ошибку.
- При попытке повторить обновление мы уйдем в бесконечную ошибку вида.
Все, конфигуратор нам больше недоступен! Чистите кэш, пытайтесь выполнить обновление ИБ, удаляйте сеансовые данные! Все бесполезно! Можете еще взять бубен, но и он бесполезен!
После этого проблема будет полностью исправлена в 99% случаев.
И это все?
Такая ошибка вас не остановит? Говорите, что ну и ладно, что в конфигуратор не вошли, зато клиенты работают, а с конфигуратором бы разобрались? Ведь решения есть на просторах интернета!
Хорошо, а как вам такой же "обрыв" соединения на этапе обновления данных в таблице "Params". Сделаем другой триггер (отключите только предыдущий):
При попытке обновления записи "DynamicallyUpdated" в таблице "Params" мы получим падение. Конфигуратор закроется системной ошибкой. Не страшно, скажите Вы! Но в этот же момент все клиентские соединения также вылетят, причем с разными ошибками. Например, с такой.
А при попытке перезапустить клиентский сеанс, также будут происходить различные ошибки. Никто не сможет работать с информационной базой!
Но и тут не все потеряно!
Клиентские сеансы не могут зайти в базу, их всех выкинуло и так далее! Но мы все еще можем в большинстве (но не во всех) случаев зайти в конфигуратор! И при повторном обновлении также в большинстве (но не во всех) случаях мы восстановим работу информационной базы!
Итог, все вылетели из базы, мы словили адреналина, и восстановили работу после штатного повторного обновления. Вас и это не убедило, что динамическое обновление очень опасно?
Вы поистине яркий человек
Если Вам и этого мало, то как Вы думаете, что будет, если оба этих случая будут комбинированы? В этом случае Вы "выкинете" всех пользователей из информационной базы, а потом еще и не сможете войти в конфигуратор повторно. Пойдете после этого вручную очищать таблицу "Config" от служебны записей динамического обновления и надеяться, что это в этот раз поможет.
Вы удивительный человек!
А ведь есть еще проблемы другого рода:
- Повреждение сеансовых данных сервера. Возникают из-за какого-то особого поведения платформы 1С, меняется от релиза к релизу, сложно прогнозируемые и сложновоспроизводимые ошибки.
- Повреждение клиентского кэша, которое приводит к:
- Ошибкам запуска клиентского приложения при входе в информационную базу
- Случайным ошибкам во время работы приложения, таким как "Тип неопределен" или подобные.
Ниже есть ссылки на примеры различных проблем и их решение. Для воспроизведения таких проблем мне пришлось бы откопать код приложений платформы 1С, но это не очень правильно.
Это весело
Вы все еще считаете, что динамическое обновление это хорошо? Что нет ни единой причины, чтобы отказаться от него? Что все описанные ошибки, которые даже можно воспроизвести прямо на свежих версиях платформы (от 8.0 до 8.3.20), не являются критичными? Может вы еще и бэкапы не делаете?
Кстати, описанные выше проблемы аткуальный как для платформы 1С версии 8.0, так и для всех более новых версий, вплоть до 8.3.20.*. И это только вершина айсберга!
Надеюсь, информация из статьи поможет кому-то хотя бы задуматься над тем, что Вы делаете!
P.S. А Вы задумывались над тем, что установка расширений тоже может приводить к подобным проблемам? :)
На нашем сайте профессионалы делятся своим опытом и разработками. Вы получаете доступ к уникальному и самому полному хранилищу материалов для 1С, состоящему из более 30 000 отчетов, обработок, видео и т.д.
Рейтинг: 504
Работая с 1С РИБами в разных конфигурациях: типовых, переписанных, отраслевых, доработанных, с расширениями и пр. Неоднократно сталкивался с различными проблемами, связанными с обменом в распределенных узлах. Например, некорректно проходит обмен, не принимается обновления конфигурации, после обновления крашится база на расширении или на объекте конфигурации, либо просто перестает запускать в режим предприятия по какой то причине. На самом деле проблемы с распределенной базой возникают довольно часто, в данной статье рассмотрим самые основные, с которыми приходилось сталкиваться. Описанные методы никогда не подводили и всегда работали, что бы с базой ни случилось. Делюсь опытом, кому-то будет спасательным кругом.
Проблемы 1С Расширения и 1С РИБа:
При появлении расширения в 1С многие простые изменения в 1С стали реализовываться через них, очень удобная штука, конфигурация находится всегда на поддержке, что безусловный плюс. Также появилась возможность расширения передавать в РИБ в версии 1С 8.3.12, указав признак "Используется в РИБ".
Но многие предпочитают делать отдельное расширение для каждого РИБа свое. Когда 1-2 РИБа еще можно внести изменения в каждое расширение, а когда их 10-15-20, то неудобно и затратно по времени.
Почему делают так? Чтобы избежать ошибок передачи самого расширения и данных. т.к. если в расширении указан признак "Используется в РИБ", то это расширение выгружается ВСЕГДА в файл обмена для узла, при каждой выгрузке (каждые 15 минут как правило). Даже если конфигурация расширения не изменялась не как, оно все равно будет выгружаться в файл обмена для распределенного узла. Это важно понимать: чем больше расширений или чем толще само расширение, тем толще и файл обмена при каждом обмене. Что может тянуть за собой разного рода проблемы.
1. Справочник "Идентификаторы объектов расширений". Первая проблема, с которой можно столкнуться после добавления расширения в центральную базу, это то, что расширение не зарегистрируется в справочнике "Идентификаторы объектов расширений", и все добавляемые в расширение изменения и объекты справочники, документы, регистры и т.д. не будут добавляться в данный справочник.
По факту мы получаем, что расширение есть в РИБе с нашими изменениями и объектами (справочники, документы и т.д.) но оно не работает в распределенной базе, либо база выпадает в ошибку, непонятно вообще откуда взятую, ведь в главной базе все то же самое работает.
Для исправления данной ситуации необходимо выполнить обновление справочника "Идентификаторы объектов расширений", делается это с помощью простой обработки (обработка приложена).По этой же причине иногда может не создаваться новая распределенная база для нового магазина, для этого требуется повторно обновить идентификаторы объектов.
2. При обмене в центральным узлом, возникает ошибка получения данных в узле. Такая ошибка, как правило, возникает при добавлении нового расширения, наша любимая фирма 1С этот баг так и не исправила, как он был с самого начала 8.3.12, так он и есть по текущую платформу 8.3.19.1264 (хотя, может, так и задумано).
После выгрузки данных из центрального узла, мы пытаемся принять данные в РИБе, в автоматическом режиме (при автообмене), либо в ручном по кнопке "Синхронизировать".
После чего получаем ошибку:
"Ошибка исключительной блокировки информационной базы
активные сеансы:
компьютер: RIB1"Подразумевается что расширение принято, но не может быть установлено, т.к. мы находимся в 1С: Предприятие, и требуется монопольный режим, и начинаются танцы с бубном.
Закрываем 1С предприятие, заходим в 1С конфигуратор, расширения нет. Заходим в 1С предприятие, делаем обмен, получаем ту же ошибку, и все по новой. Замкнутый круг. Расширение не принимается, и обмен перестает работать.
Вот тут и заключается баг от фирмы 1С, после добавления нового расширения в центральный узел и выгрузки его в РИБ, первый обмен в распределенном узле необходимо сделать через "Сценарий обмена".
Для этого в синхронизации необходимо войти в меню "Еще-Сценарий синхронизации данных", и там нажать кнопку "Выполнить сценарий". Иногда также требуется отключить "Выгрузку" и оставить только сценарий "Загрузки", если это один и тот же сценарий.
При таком способе расширение ставиться корректно и нам стоит только перезапустить 1С Предприятие, чтобы принять изменения и сделать синхронизацию в штатном режиме (она пройдет без ошибок).3. Важно следить за совместимостью конфигурации и расширения. Еще один немаловажный момент, необходимо просмотреть расширение после обновления конфигурации или 1С платформы, обновить объекты конфигурации расширения, заменить их, изменить процедуры, которые могли измениться в обновлении, переключить совместимость расширения, если совместимость конфигурации изменилась. При сохранении и проверки есть такой механизм, но он не всегда корректно может отработать.
Немного отступления, был случай, который выпил много крови. Обновляли базу УТ 11.4 до последнего релиза в связи с маркировкой, обновили платформу т.к. новая УТ 11.4 не работала на той платформе, обновили РИБы (3 штуки) саму базу данных 1С и платформу соответственно. В базе было 2 расширения с доработками под нужды компании. Все работало все рады.
Через пару месяцев потребовалось внести небольшое изменения в расширения, вносится изменения, после обновления, база крашится в дамп и перестает напрочь работать. В режим 1С Предприятие не пускает, в режим конфигуратора входит но при попытке открыть список расширения дамп.
Ошибок по журналу нет, тесты базы через конфигуратор или через утилиту chdbfl проходят без ошибок, кэш не помогает, удаление расширений не помогает. Было ясно одно, что проблема с расширением, т.е. все работает, пока не трогаем расширение (восстанавливали неоднократно базу, пока не нашли причину). А причина была проста. Совместимость конфигурации была намного выше совместимости расширения, плюс ко всему платформа уже была 8.3.19. И проблемы в работе не было, т.е. 1С не выдавала ошибок совместимости или еще что-то, пока не поменяли структуру расширения, и тогда 1с очнулась, что вы нам тут втюхиваете. ушло 2 дня на поиски проблемы, а оказалось простая вещь.
Ложкой дегтя было еще и то, что просто совместимость не изменить, т.к. после сохранения база крашилась, пришлось откатываться по платформе и на платформе 8.3.16 изменять совместимость, и потом уже все остальное. После того, как указали правильную совместимость, обмены пошли в штатном режиме, и все работало корректно и дальше.
4. Удаление расширения в центральном узле и распределенных базах. Если необходимо удалить расширение из базы, которое используется в распределенных базах, то его необходимо:
- Отключить в центральной базе, после чего во всех РИБах принять это изменение, что оно отключено и больше не используется;
- После того как во всех РИБах оно будет отключено, его можно удалять из центрального узла.Если отключить и удалить расширение из центрального узла, которое ранее использовалось в распределенных базах, без принятия изменений об отключении в РИБах. То эти расширения зависают в распределенных узлах и их нельзя ни отключить, ни удалить, т.к. они идут из центрального узла. В связи с чем синхронизация не проходит, т.к. состав расширений и конфигурации не соответствует центральному узлу.
В итоге получается, что в распределенной базе есть расширение, а в центральном узле его нет, и информация в распределенный узел не передана об его отключении.
- Обязательно! Делаем копию БД (если что-то пойдет не так);
- Отключаем в распределенной базе центральный узел, это можно сделать с помощью обработки;Также отключить подчиненный узел от главного узла можно с помощью параметра запуска конфигуратора /ResetMasterNode.
"C:\Program Files (x86)\1cv8\common\1cestart.exe" config /f "D:\1C\ПапкаБазы" /n администратор /p пароль /ResetMasterNodeУдаление расширений через командную строку
Для удаления всех расширений (файловый вариант):
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /f "Полный_путь_к_базе" /N "Имя_пользователя" /P "Пароль_пользователя" /DeleteCfg -AllExtensions
Для удаления одного расширения по имени (файловый вариант):
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /f "Полный_путь_к_базе" /N "Имя_пользователя" /P "Пароль_пользователя" /DeleteCfg -Extension "ИмяРасширения"
Для удаления одного расширения по имени (серверный вариант, SQL):
"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /S «ИмяСервера/ИмяИнформБазы» /N "Имя_пользователя" /P "Пароль_пользователя" /DeleteCfg -Extension "ИмяРасширения"
- После отключения узла заходим в конфигуратор и удаляем расширения, которых нет в центральной базе, и сохраняем базу;
- При первом входе в базу в режиме предприятия 1С спросит восстановить узел ВАЖНО его ВОССТАНОВИТЬ. ;
- После чего синхронизация проходит в штатном режиме.5. Другие проблемы с расширениями. Прочие проблемы с расширениями при обмене.
- Нет доступа к файлу (если ранее все работало)
- файл не обнаружен Params\DBNames. и т.д.Такие ошибки как правило возникают из-за зависшего кэша, и исправляются чисткой 1с КЭШа: "C:\Users\User\AppData\Local\1C\".
6. Восстановление узла распределенной информационной базы (при изменении конфигурации). Бывает, при изменении конфигурации центрального узла и выгрузке в распределенную базу, после синхронизации 1С говорит, что было принято изменение и надо обновить 1С, после обновление. Делаем синхронизацию повторно и опять то же самое и так бесконечно, изменения не принимаются, чтобы вы ни пытались с распределенной базой сделать.
Для исправления данной ошибки требуется сделать следующие шаги:
- Обязательно! Делаем копию БД (если что-то пойдет не так);
- Выгружаем конфигурацию главного узла в файл *.cf в режиме конфигуратора.
- Отключаем в распределенной базе центральный узел, это можно сделать с помощью обработки;Также отключить подчиненный узел от главного узла, можно с помощью параметра запуска конфигуратора /ResetMasterNode.
"C:\Program Files (x86)\1cv8\common\1cestart.exe" config /f "D:\1C\ПапкаБазы" /n администратор /p пароль /ResetMasterNodeПример: "C:\Program Files (x86)\1cv8\8.3.19.1150\bin\1cv8.exe" config /ResetMasterNode
Также этот метод поможет вам если, при обновлении конфигурации были проблемы и ошибки и режим предприятия не работает или вылетает ошибка при синхронизации или обновлении.
- Загружаем конфигурацию главного узла из файла *.cf в подчиненный узел в режиме конфигуратора. Загружаем полной заменой "Загрузить конфигурацию из файла", не сравнить, объединить конфигурации;
- При первом входе в базу в режиме предприятия 1С спросит восстановить узел ВАЖНО его ВОССТАНОВИТЬ. Либо восстановить главный узел можно с помощью обработки;
- После чего синхронизация проходит в штатном режиме.
После выполнения этих действий работоспособность распределенной информационной базы будет восстановлена.
Внимание! Важный момент на "19" платформе (8.3.19.1150, 8.3.19.1467) очень много проблем с расширениями их обновлениям и доработкой. В один прекрасный день после очередного изменения или доработки расширение, 1с начнет падать в дамп (ошибку), не давай обновить расширение. Лечится либо откатом на "18" платформу либо на "20", если такой возможности нет, выгружаете базу разворачивайте на другой платформе обновляете или исправляете расширение и грузите базу назад. 1С и само расширение работает нормально и после проделанной работы. Способ рабочий.
Надеюсь, описанный опыт кому-то поможет и сэкономит кучу времени по решению проблем, возникших в распределенных базах.
Это означает, что программа 1С определила, что файл с базой перемещён по другому пути, возможно даже на другой компьютер в сети.
При копировании информационной базы в другое местоположение возможны ситуации, когда обе информационные базы (и исходная и скопированная) продолжают взаимодействовать с внешними ресурсами (например, выполнение рассылки отчетов, синхронизация данных с другими программами, отправка или получение почты и т.п.). Для предотвращения таких ситуаций при первом входе в перемещенную базу администратор должен принять решение информационная база была перемещена или это копия информационной базы.
Если ответим «Информационная база перемещена», то 1С посчитает эту базу основной и ничего предпринимать не будет.
Если ответим «Это копия информационной базы», то 1С пометит для себя эту базу как копию и тут же заблокирует работу со всеми внешними ресурсами (синхронизация данных, синхронизация файлов с облачным сервисом, отправка и получение почты и т.п.).
Если Вы ошиблись в ответе и случайно ответили «Это копия информационной базы».
Чтобы сделать копию базы снова основной и разблокировать работу с внешними ресурсами нужно зайти в раздел Администрирование пункт Поддержка и обслуживание.
Открываем раздел Регламентные операции и затем нажимаем Разблокировать работу с внешними ресурсами.
Читайте также: