Содержание
Дано
При применении конфигурации в РИБ возникает критическая ошибка и конфигуратор аварийно завершается.
Затем, при попытке зайти в конфигуратор, 1С выдает следующее сообщение: «При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?”
Выбор любого из действий ни к чему не приводит и если ответить утвердительно, то повтор обновления не происходит.
Попытка вернуться к конфигурации БД через параметр командной строки /RollbackCfg так же не увенчалась успехом. При использовании этого метода в диспетчере задач видно, что 1С запускается на 2-3 секунды и даже не успевает развернуться в памяти, и фактически не отрабатывает.
Версия платформы 8.3.13.1809 (клиент-сервер)
Решение
На просторах интернета конечно же есть решение, которое реально помогает, но нужно заметить его небезопасность и то, что все действия нужно выполнять с осторожностью перепроверяя свои действия.
Итак суть решения состоит в том чтобы очистить некоторые данные в таблицах БД (SQL), которые говорят системе о незавершенном обновлении. Нужно выполнить запросы к БД.
Конечно же я настоятельно рекомендую выполнять все действия при наличии резервной копии БД, причем средствами сервера БД. Но если на это нет времени, то мы себя немного обезопасим резервной копией таблиц.
Кстати о возможности возврата к отправной точке, первые два select копируют две таблицы, с которыми мы будем выполнять действия и создают временные таблицы Config_tmp и ConfigSave_tmp на всякий случай для возможности возврата.
первый из delete удаляет все данные таблицы ConfigSave.
остальные удаляют определенные записи из таблицы config.
После выполнения этих действий вы сможете зайти в 1С в режиме конфигуратора, при этом все ваши изменения будут потеряны.
Если все прошло удачно, то нужно удалить временные таблицы которые мы создавали.
Рассмотрим два пути, если при открытии программы 1С появляется сообщение:
Рис.1 Сообщение
Можно согласиться и продолжить действие (тогда программа запустится, и в ней можно будет работать дальше) или отказаться и решить проблему. Если мы решили пойти вторым путем, нам нужно понять, в чем же состоит причина данного сообщения.
- Первое – при выполнении обновления. Обновление не прошло до конца по каким-либо причинам: вышли из программы, не приняв их, или же просто произошел сбой при выполнении, и процесс не был завершен (если программа наша открывается при этом – это уже хорошо).
- Второй вариант – кто-то случайно (или в процессе разработки) внес правки, и соответственно они также остались незавершенными, не принятыми программой. Проанализировав ситуацию, необходимо сделать вывод, нужно ли просто принять сделанные правки или придется возвращать базу в исходное состояние.
В обоих случаях просто не выполнена реструктуризация, поэтому ее нужно обновить и, если нужно, привести в соответствие с основной конфигурацией.
Рассмотрим, как решить эти вопросы, не забывая, что перед любыми действиями с информационной базой, рекомендуется сделать ее резервную копию.
Рис.2 Выгрузка ИБ
Для решения проблемы заходим в базу через Конфигуратор.
Рис.3 Для решения проблемы заходим в базу через Конфигуратор
Когда действительно имело место обновление, не завершившее процесс, или разработчиками все-таки вносились нужные, но не завершившиеся изменения, нам надо дать команду программе – завершить процессы. Обратите внимание на заголовок окна конфигурации. Там стоит восклицательный знак . Это говорит о том, что наша конфигурация изменена и отличается от конфигурации БД. Завершаем нашу операцию через одноименный пункт меню.
Рис.4 Завершаем нашу операцию через одноименный пункт меню
Или для выполнения этого же действия можно использовать кнопку на панели инструментов в виде синего цилиндра со стрелочкой.
Рис.5 Кнопка на панели инструментов в виде синего цилиндра со стрелочкой
Обратите внимание на горячие клавиши в подсказке. С клавиатуры это действие может быть выполнено нажатием функциональной клавиши F7.
Программа выполнит обновление, принимаем все изменения и можем заходить в программу. Сообщение больше появляться не будет.
Восстановление исходного состояния информационной базы
Если в конфигурацию были внесены случайные изменения, или программист (разработчик) вносил изменения в конфигурацию, после чего были обнаружены ошибки, исправить которые проблемно, можно восстановить ее, заменив измененные метаданные метаданными из конфигурации базы данных. Для этого в уже используемом нами пункте меню заходим в раздел «Вернуться к конфигурации БД».
Рис.6 Вернуться к конфигурации БД
Программа предупредит, о потере изменений, сделанных в программе, но мы соглашаемся на продолжение выполнения действия.
Рис.7 Программа предупредит, о потере изменений, сделанных в программе, но мы соглашаемся на продолжение выполнения действия
После окончания процесса метаданные нашей конфигурации будут соответствовать основной.
117 пользователя считают данную страницу полезной. Информация актуальна! Страница была обновлена 16.12.2019
Раздел содержит перечень данных, описывающих кластер серверов 1С:Предприятия 8.1, и их расположение. Для наиболее важных данных даны пояснения к их хранению. Раздел не содержит исчерпывающего описания всех данных, управляющих работой кластера.
Рабочий каталог центрального сервера
При установке на компьютер сервера 1С:Предприятия 8.1 происходит выбор рабочего каталога центрального сервера. Обычно, этот каталог «C:Program Files1cv81server», который располагается рядом с каталогом загрузочных модулей 1С:Предприятия 8.1. Этот каталог указывается в строке запуска агента сервера 1С:Предприятия 8.1 при его регистрации в качестве сервиса Windows.
При запуске агента сервера 1С:Предприятия 8.1 ему может быть указан рабочий каталог центрального сервера. Для этого используется параметр -d. Например:
Если параметр -d не указан, то в качестве рабочего каталога центрального сервера используется каталог:
где – имя пользователя Windows, от имени которого стартует агент сервера 1С:Предприятия 8.1.
В рабочем каталоге центрального сервера располагается файл управления агентом и рабочие каталоги кластеров, которые зарегистрированы на данном компьютере.
Файл списка кластеров
Список кластеров имеет имя srvribrg.lst. Ниже приведен пример его содержимого с пояснениями:
Файл состоит из двух частей. В первой части перечислены кластеры, которые зарегистрированы на данном компьютере. В соответствии с этой информацией агент сервера (ragent) запускает на данном компьютере процессы менеджеров кластеров (rmngr). В приведенном примере к списку кластеров относятся строки:
Здесь зарегистрированы два кластера с описаниями «Локальный кластер» и «Второй кластер», имеющие порты, соответственно, 1541 и 1641. Оба кластера расположены на данном компьютере, имя или IP адрес которого – server_name.
Важно, что при изменении имени или адреса данного компьютера, а также при копировании рабочего каталога кластера на другой компьютер, имя или IP адрес компьютера должны быть изменены в файле управления агентом. Иначе кластер серверов стартовать не сможет.
При первом запуске агента сервера после установки он создает кластер по умолчанию. При этом список кластеров обычно выглядит так:
Если при первом запуске агента кластера возникли какие-либо проблемы, то кластер по умолчанию может быть не создан. Это проявляется в том, что при запуске агента сервера (ragent) он стартует, но не запускает другие процессы кластера (rmngr, rphost). Список кластеров при этом выглядит так:
В этом случае можно остановить процесс ragent, удалить список кластеров (srvribrg.lst) и запустить ragent снова. Кроме того, кластер может быть создан при помощи утилиты администрирования клиент-серверного варианта работы.
Вторая часть файла списка кластеров содержит список администраторов центрального сервера. В приведенном примере к нему относятся строки:
Наличие хотя бы одного администратора в этом списке требует аутентификации администратора центрального сервера при создании нового кластера. Пустой список администраторов центрального сервера имеет вид:
Рабочий каталог кластера
Рабочие каталоги кластеров располагаются в рабочем каталоге центрального сервера под именами reg_ . Например, для кластера с портом 1541 рабочий каталог кластера будет иметь имя reg_1541. Он создается при создании кластера и содержит всю информацию о работе кластера. При удалении кластера при помощи утилиты администрирования клиент-серверного варианта работы рабочий каталог кластера сохраняется. В рабочем каталоге кластера содержится файл реестра кластера и рабочие каталоги информационных баз.
Файл реестра кластера
Файл реестра кластера содержит общие параметры кластера и списки:
- рабочих серверов,
- рабочих процессов,
- информационных баз,
- администраторов кластера.
Ниже приведен пример файла реестра кластера с пояснениями.
Файл состоит из 5 разделов. Первый раздел включает строки:
и содержит общие параметры кластера, которые можно увидеть среди свойств кластера в утилите администрирования клиент-серверного варианта работы. Имя или IP адрес центрального сервера кластера (server_name_1) должен быть изменен при изменении имени или IP адреса центрального сервера кластера или в случае копирования файла реестра кластера на другой компьютер.
Второй раздел файла в приведенном примере содержит строки:
и определяет список информационных баз, зарегистрированных в кластере. В приведенном примере определены две информационные базы. Первая с именем InfoBase1 расположена на Microsoft SQL Server с именем db_server1 в базе данных dbname1, вход в SQL Server выполняется от имени пользователя dbuser1. Вторая с именем InfoBase2 расположена на IBM DB2 с именем db_server2 в базе данных dbname2, вход в IBM DB2 выполняется от имени пользователя dbuser2. Содержимое этого раздела меняется при помощи утилиты администрирования клиент-серверного варианта работы при создании/ удалении информационных баз. Изменять этот раздел непосредственно не рекомендуется.
Следующий раздел определяет список рабочих процессов кластера. В приведенном примере к нему относятся строки:
Здесь определено два рабочих процесса, запускаемых на рабочих серверах server_name_1 (этот же компьютер выполняет функции центрального сервера) и server_name_2. Для каждого рабочего процесса хранится статистическая информация, собранная в процессе его работы. Имена или IP адреса рабочих серверов должны быть изменены при изменении имен или IP адресов рабочих серверов, а также при копировании файла реестра кластера на другой компьютер.
Четвертый раздел определяет список администраторов кластера. В приведенном примере он состоит из строк:
В примере определены два пользователя с идентификаторами user1 и User2, именами «Пользователь 1» и «Пользователь 2», причем для пользователя User2 задана аутентификация операционной системы. Если этот список не пустой, то для просмотра и изменения любых данных кластера при помощи утилиты администрирования клиент-серверного варианта работы или объекта V81.COMConnector требуется аутентификация администратора кластера.
Последний раздел содержит список рабочих серверов кластера. В нашем примере к нему относятся строки:
Здесь определены два сервера с именами server_name_1 и server_name_2. На обоих серверах агент сервера использует порт 1540 и выделены диапазоны динамического распределения IP портов с 1560 по 1591. Имена или IP адреса рабочих серверов должны быть изменены при изменении имен или IP адресов рабочих серверов, а также при копировании файла реестра кластера на другой компьютер.
Рабочий каталог информационной базы
В рабочем каталоге кластера могут располагаться рабочие каталоги информационных баз. Имя рабочего каталога информационной базы совпадает с ее идентификатором в файле реестра кластера. Например, рабочий каталог информационной базы InfoBase1 из приведенного выше примера будет называться 63e734a9-d0dc-4cd9-bcdf-4ede41666a24.
В рабочем каталоге информационной базы содержатся профайлы информационной базы, журнал регистрации (подкаталог 1Cv8Log), служебные данные системы полнотекстового поиска и некоторые другие данные.
Маленький IT блог с характером 1С.
четверг, 14 июля 2016 г.
Миграция на новую версию сервера 1С:Предприятия
Данный метод справедлив для клиент-серверного варианта работы! Первым шагом выполняем создание резервной копии информационной базы (ИБ). Выполнить создание резервной копии можно различными способами, как средствами конфигуратора, так и средствами СУБД.
При работе в клиент-серверном варианте используется трехуровневая архитектура с использованием кластер серверов 1С:Предприятия, через который выполняется общение клиентской части 1С:Предприятия и СУБД.
После создания резервной копии, удаляем информационную базу в кластере серверов 1С:Предприятия старой версии (допустим, версии 8.2), связанную с базой данных СУБД, которая хранит данные информационной базы. Перед удалением запоминаем имя базы данных в СУБД.
У сервера 1С:Предприятие нет собственного пользовательского интерфейса (GUI), для управления им используется консоль администрирования кластера серверов, ее можно установить при установке платформы 1С.
Что бы выполнить данную операцию, открываем консоль администрирования кластера старой версии, выделяем необходимую информационную базу. Правой кнопкой мыши вызываем контекстное меню и выбираем пункт Свойства, откроется окно параметров информационной базы, в котором в свойстве База данных будет отображаться имя базы данных (см. рисунок 1), запоминаем его.
Рисунок 1. Параметры информационной базы
Повторно вызываем контекстное меню и нажимаем на кнопку Удалить (см. рисунок 2).
Рисунок 2. Удаление информационной базы из кластера
Консоль предложит три варианта удаления (см. рисунок 3):
- удалить базу – информационная база удаляется в кластере, база данных в СУБД так же удаляется;
- очистить базу данных – информационная база удаляется в кластере, из базы данных удаляются все данные информационной базы;
- оставить без изменений – информационная база удаляется в кластере, но данные ИБ остаются в базе данных.
Рисунок 3. Режимы удаления информационной базы
Выбираем третий вариант. Теперь кластер серверов старой версии не знает о существовании базы данных в СУБД, которая хранит данные удаленной информационной базы.
Следующим шагом нужно «рассказать» новому кластеру серверов (допустим, версии 8.3) о существовании базы данных в СУБД, в которой содержатся данные удаленной информационной базы. Для этого открываем консоль администрирования кластера новой версии и создаем новую информационную базу (см. рисунок 4).
Рисунок 4. Создание новой информационной базы через консоль кластера
В окне создания новой информационной базы указываем новые параметры создания, только в свойстве База данных указываем имя базы данных, которое запомнили при удалении информационной базы (см. рисунок 1 и 5).
Рисунок 5. Параметры новой информационной базы
Данным действием связывается новая информационная база с данным в базе данных. После работ с консолью, в окне запуска 1С:Предприятия для существующей информационной базы изменяем параметры информационной базы (см. рисунок 6):
- Кластер серверов 1С:Предприятия – указываем адрес нового кластера;
- Имя информационной базы в кластере – указываем новое имя (см. рисунок 5).
Рисунок 6. Новые параметры подключения информационной базы в окне запуска
Запускаем конфигуратор информационной базы от имени пользователя с правами администрирования ИБ, конфигуратор может запросить подтверждение на конвертацию структуры ИБ под новую версию платформы 1С, соглашаемся.
Действия по переходу на новую платформу завершены.
Как создать базу
Открываем 1С и нажимаем кнопку «Добавить»
Выбираем «Создание информационной базы» и нажимаем «Далее»
Нажимаем «Создание информационной базы без конфигурации для разработки новой конфигурации или загрузки выгруженной ранее информационной базы»
Указываем название базы, выбираем тип расположения «На данном компьютере или на компьютере в локальной сети»
Указываем каталог информационной базы (рекомендуем использовать для размещения базы локальный диск D:)
Оставляем галочки «Выбирать автоматически» и нажимаем «Готово»
В результате создана пустая база, куда можно загрузить требуемую конфигурацию.
Как удалить базу
Откроем программу 1С, выберем нужную базу и внизу видим путь к базе на диске
Открываем папку Buh_2 (в нашем случае) видим файлы базы:
Их нужно удалить, а также удалить и папку, если в ней нет других данных.