Не открывается база 1С 8.3: как исправить

База 1С 8.3 может не открываться по нескольким типичным причинам: зависший сеанс на сервере, повреждение файла базы, проблемы с доступом к папке или SQL-серверу, а также ошибки после некорректного завершения работы. Правильная диагностика — половина решения: ошибка «Файл базы данных поврежден» требует одних действий, а «Ошибка соединения с сервером 1С» — совершенно других.

Первое правило — не запускать подряд все известные способы восстановления. Некоторые операции, например тестирование и исправление с включёнными опциями удаления данных, необратимо изменяют базу. Перед любыми действиями сделайте резервную копию: для файловой базы достаточно скопировать файл 1Cv8.1CD, для клиент-серверной — выполнить выгрузку в dt или средствами СУБД.

Ниже разобраны основные сценарии: от простых (зависший процесс, нет прав на папку) до серьёзных (повреждение файла базы, проблемы MS SQL или PostgreSQL). Для каждого случая приведены признаки, порядок действий и способ проверить результат.

Определяем тип базы и характер ошибки

Порядок восстановления зависит от того, как развёрнута база. Файловая база — это файл 1Cv8.1CD в папке на диске или сетевом ресурсе. Клиент-серверная — данные на MS SQL Server, PostgreSQL или Oracle, к которым платформа обращается через сервер 1С:Предприятия. Узнать тип можно в списке баз стартера 1С: выделите базу и посмотрите строку подключения внизу окна.

Текст ошибки — главный диагностический признак. «Ошибка разделенного доступа к базе» указывает на монопольный режим или зависший сеанс. «Файл базы данных поврежден» — на физическую проблему с 1Cv8.1CD. «Ошибка соединения с сервером» — на недоступность агента сервера или СУБД. Зафиксируйте точный текст ошибки до начала работ.

Проверяем зависшие сеансы и монопольный режим

Если база сообщает, что уже используется, или конфигуратор не запускается с требованием монопольного доступа, причина почти всегда в активных сеансах. В клиент-серверном варианте откройте консоль администрирования сервера 1С, раскройте нужную базу и посмотрите список сеансов. Завершите зависшие сеансы принудительно — пользователи при этом потеряют несохранённые данные, поэтому предупредите их заранее.

В файловом варианте зависший сеанс — это процесс 1cv8.exe на компьютере пользователя, который не закрылся корректно. Проверьте диспетчер задач на всех машинах, работающих с базой, и завершите «подвисшие» процессы. Также удалите блокировочные файлы в папке базы, если они остались после аварийного завершения — рядом с 1Cv8.1CD не должно быть лишних служебных файлов при закрытой базе.

После очистки сеансов попробуйте открыть базу в режиме «Предприятие», а затем в конфигураторе. Если монопольный режим по-прежнему недоступен, проверьте, не запущены ли фоновые задания — они тоже удерживают соединения.

1. 1
   Сделайте копию файла базы или выгрузку dt
2. 2
   Откройте консоль кластера и завершите зависшие сеансы
3. 3
   На файловой базе проверьте и завершите процессы 1cv8.exe на всех ПК
4. 4
   Перезапустите службу агента сервера 1С при клиент-серверном режиме
5. 5
   Откройте базу в режиме Предприятие и проверьте работу

Проверяем права доступа и доступность папки с базой

Файловая база на сетевом ресурсе часто «не открывается» из-за банальной недоступности папки: отвалился сетевой диск, изменились права, папку переименовали. Проверьте, что путь из списка баз открывается в проводнике Windows и файл 1Cv8.1CD на месте. Если база перенесена, удалите старую запись в списке баз и добавьте базу заново с актуальным путём.

Учётная запись, под которой запускается 1С, должна иметь полные права на папку базы: чтение, запись, изменение, создание и удаление файлов. Для клиент-серверного варианта права нужны учётной записи службы агента сервера 1С (по умолчанию USR1CV8) на рабочий каталог сервера, а также корректная авторизация на СУБД.

Отдельный источник проблем — антивирус, блокирующий файл базы при проверке в реальном времени. Добавьте папку с базой и каталоги платформы в исключения антивируса и проверьте, открывается ли база после этого.

Восстанавливаем повреждённую файловую базу

Повреждение 1Cv8.1CD случается при аварийном выключении питания, сбоях диска, разрыве сети при работе по сети и переполнении диска. Признаки: ошибка «Файл базы данных поврежден» при запуске, вылеты при обращении к конкретным документам или справочникам, ошибки при выгрузке.

Первый инструмент — утилита chdbfl.exe из каталога bin установленной платформы. Она проверяет физическую целостность файла и может исправить повреждения на уровне структуры таблиц. Укажите путь к 1Cv8.1CD, включите опцию «Исправлять обнаруженные ошибки» и дождитесь завершения. Утилита работает только с монопольным доступом к файлу — база не должна быть открыта никем.

Второй этап — «Тестирование и исправление» в конфигураторе. Запустите конфигуратор, откройте меню «Администрирование — Тестирование и исправление». Начните с проверок «Реиндексация таблиц» и «Проверка логической целостности» в режиме «Тестирование и исправление». Опции «Очистка ссылок» с удалением объектов используйте осознанно: они физически удаляют битые данные.

chdbfl.exe — утилита проверки физической целостности, находится в каталоге: C:\Program Files\1cv8\<версия платформы>\bin\chdbfl.exe. Запуск: указать файл 1Cv8.1CD, отметить «Исправлять обнаруженные ошибки», нажать «Выполнить».

Решаем проблемы клиент-серверного варианта

Если база на SQL не открывается, проверьте три уровня: службу агента сервера 1С, службу СУБД и сетевую связность между ними. Откройте services.msc и убедитесь, что службы «Агент сервера 1С:Предприятия» и, например, «SQL Server (MSSQLSERVER)» запущены. Перезапустите их при подозрении на зависание.

Частая причина после перезагрузки сервера — служба СУБД стартует позже агента сервера 1С, и базы оказываются недоступны. Настройте отложенный запуск агента или зависимость служб. Также проверьте, что база данных в SQL Server находится в состоянии ONLINE, а не в SUSPECT или RECOVERY PENDING — это видно в SQL Server Management Studio.

Если база в состоянии SUSPECT, самостоятельные эксперименты опасны: неправильные команды могут привести к потере данных. Безопасный путь — восстановление из последней резервной копии средствами СУБД. Команду DBCC CHECKDB с REPAIR_ALLOW_DATA_LOSS применяйте только как крайнюю меру и только на копии базы.

Очищаем кэш и проверяем платформу

Кэш метаданных иногда становится причиной странного поведения: база не открывается у одного пользователя, конфигуратор выдаёт ошибки формата потока, интерфейс «ломается». Кэш находится в профиле пользователя: %APPDATA%\1C\1cv8 и %LOCALAPPDATA%\1C\1cv8. Закройте 1С, удалите папки с именами в виде длинных идентификаторов (это кэш конкретных баз) и запустите базу заново.

Ещё один вариант — удалить базу из списка в стартере и добавить заново: при этом кэш привязки очищается автоматически. Данные при этом не затрагиваются, операция безопасна.

Проверьте также версию платформы: если базу обновили на более новой платформе, а открываете старой, возможны ошибки несовместимости. Убедитесь, что на компьютере установлена платформа требуемой версии, и в настройках базы в списке указана она.

Проверяем результат и профилактика повторов

После восстановления проверьте базу комплексно: откройте её в режиме «Предприятие» под обычным пользователем, выполните типовые операции (проведение документа, формирование отчёта), затем запустите «Тестирование и исправление» только в режиме проверки без исправлений — ошибок быть не должно.

Чтобы проблема не повторилась, настройте регулярное резервное копирование: выгрузку dt по расписанию для файловых баз и штатные бэкапы средствами СУБД для клиент-серверных. Проверьте источник бесперебойного питания на сервере, здоровье дисков (SMART, тесты) и стабильность сети. Большинство повреждений баз — следствие внешних сбоев, а не платформы.

Частые вопросы