Управляем общими списками баз 1С: настройка и оптимизация

3 сентября 2026 · infolimp.ru

Анатомия списка баз: что вы видите в окне запуска

Любой список баз в клиенте 1С:Предприятие 8 — это результат чтения нескольких текстовых файлов с расширением V8I, лежащих в профиле пользователя. Обычно это папка %APPDATA%\1C\1CEStart\ и аналогичные системные каталоги. Файл Default.v8i создаётся автоматически при первом запуске, в него попадают базы, добавленные через интерфейс. Если администратор распространяет «общий список», по факту это просто ещё один V8I, который кладётся в ту же папку или в сетевой каталог, указанный в настройках клиента.

Структура файла V8I

Формат — классический INI: секции, ключи, значения. Каждая база описывается набором параметров: имя, расположение, строка соединения, идентификатор. Пример фрагмента реального файла:

[База]
Имя=Бухгалтерия предприятия
Расположение=Сервер=SRV1:2541;БД=Accounting;
СтрокаСоединения=Бухгалтерия предприятия
Идентификатор=abc12345-0000-0000-0000-000000000000

Клиент читает такие секции последовательно и строит дерево в окне запуска. Если в одном файле несколько баз — они группируются по имени секции. Однако настоящая проблема начинается, когда таких файлов несколько: клиент выполняет слияние по идентификаторам баз, а при совпадении имён или адресов могут возникать дубликаты.

Централизованное управление общими списками: два пути

Есть два принципиально разных подхода, и выбор между ними — компромисс между простотой внедрения и управляемостью.

Путь первый: физическая рассылка файлов

Вы формируете эталонный V8I на сервере, а затем скриптом или через логин-скрипт копируете его в %APPDATA%\1C\1CEStart\ каждому пользователю. Плюсы — работает даже офлайн, скорость запуска не зависит от сети. Минусы — при добавлении или удалении базы надо пересоздавать файл и обновлять его на всех машинах. Если пользователь добавил свою базу в тот же файл, следующая копия его перезапишет, и локальные данные потеряются.

Путь второй: сетевой каталог с общими V8I

В настройках клиента можно указать дополнительную папку для поиска файлов V8I (обычно это делается через реестр или командную строку). Вы размещаете один общий файл на файловом сервере, а на рабочих станциях прописываете путь к нему. Преимущество — централизованное обновление: поменяли файл на сервере — все увидели изменения после перезапуска клиента. Недостаток — если сервер недоступен, клиент при старте долго ждёт таймаут, и общий список становится пустым. Поэтому сетевой каталог рекомендуется использовать только в быстрых надёжных ЛВС.

Сравнение подходов в таблице

Если у вас больше 50 машин и нет системы управления конфигурациями — сетевой файл спасёт от бесконечного ручного копирования. Но сначала проверьте время доступа к серверу с типичного рабочего места.

Невидимая ловушка: кодировка и структура V8I

Казалось бы, что может пойти не так после редактирования текстового файла? Всё идёт не так из-за кодировки. Файлы V8I должны быть в UTF-8 с BOM. Если вы открыли V8I в стандартном «Блокноте» Windows и сохранили (особенно на системах с русской локалью), Блокнот перекодирует его в ANSI (Windows-1251). После этого 1С при чтении неправильно интерпретирует байты: имена баз превращаются в «кракозябры», а иногда базы вообще исчезают — клиент молча пропускает записи, которые не смог разобрать.

// Правильный программный способ прочитать и записать V8I
// Не используйте Блокнот для редактирования файлов списка баз.

Чтение = Новый ЧтениеТекста(ПутьКФайлу, Кодировка.UTF8, ИспользованиеBOM.Да);
Строка = Чтение.Прочитать();
Чтение.Закрыть();

// Модифицируем строку...

Запись = Новый ЗаписьТекста(ПутьКФайлу, Кодировка.UTF8, ИспользованиеBOM.Да);
Запись.Записать(Строка);
Запись.Закрыть();

Обратите внимание: при чтении обязательно указывайте ИспользованиеBOM.Да, иначе первый символ файла (метка BOM) попадёт в содержимое и вызовет ошибку при следующем запуске. Если вы редактируете V8I вручную, используйте редактор, который поддерживает UTF-8 BOM (например, Notepad++ или VS Code с настройкой кодировки). После сохранения проверьте первый символ — он не должен быть видимым.

Оптимизация: почему старт клиента тормозит и что с этим делать

Механика задержек

При открытии окна запуска клиент собирает все V8I из назначенных каталогов, затем для каждой серверной базы пытается установить соединение с сервером, чтобы проверить её доступность. Если в списке есть базы с неактуальными адресами (например, сервер уже переехал), клиент ждёт сетевого таймаута — обычно несколько секунд на базу. Десять таких «мусорных» записей — и запуск занимает полминуты.

Вторая причина — слишком большой сам файл V8I. Чтение мегабайта текста само по себе быстрее, чем кажется, но каталоги с сотнями файлов замедляют работу и создают лишнюю нагрузку на диск. Особенно это заметно на медленных виртуальных машинах.

Что реально помогает

• Удаляйте из общих списков базы, которые давно не используются. Храните «историю» в отдельном V8I вне каталога поиска.
• Настройте таймаут соединения для клиента через параметры запуска или реестр (не в V8I). Но это типовое решение для всей организации, применять его стоит осознанно.
• Используйте группы в файле V8I, чтобы пользователь не видел все базы сразу. Группируйте по отделам или назначению — сам факт меньшего количества записей ускоряет первичный рендер окна.
• Если базы лежат на нескольких серверах, укажите в строке соединения сервер с портом — это исключит лишнюю попытку обнаружения сервиса 1C:Enterprise 8 Server по умолчанию.

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

Чек-лист администратора и типичные ошибки

Типичные ошибки

1. Редактирование V8I в Блокноте. Приводит к потере BOM и нечитаемым кириллическим именам. Всегда проверяйте кодировку.
2. Копирование файла поверх пользовательского. Уничтожает локальные настройки и личные базы. Используйте отдельные файлы для общих списков, а не перезаписывайте Default.v8i.
3. Отсутствие проверки доступности серверов. Добавили новую базу — и она «висит» с таймаутом, стопоря остальные.
4. Смешивание локальных и общих списков в одном файле. Пользователь не может удалить базу из общего списка, потому что она появится снова после перезапуска.
5. Игнорирование параметра /IBName для пользователей, которым нужна одна база. Это и время экономит, и окно запуска не мешает.

Что делать прямо сейчас

1. Сделайте резервную копию файлов *.v8i из профилей пользователей.
2. Определите, какие базы действительно нужны общие, и соберите их в один эталонный V8I с корректной структурой и кодировкой UTF-8 BOM.
3. Разместите эталонный файл на сервере в папке с ограниченным доступом (только чтение для пользователей).
4. Настройте клиент на поиск этой папки — через реестр или параметр командной строки, либо через логин-скрипт, который подкладывает файл в профиль с чётким именем, например Common.v8i.
5. Убедитесь, что в файле нет базы с устаревшими серверами. Проверьте каждую запись, запуская клиент с /IBName для каждой базы.

Управление списками баз — это рутина, которая не прощает халатности. Половина проблем, описанных выше, не проявляется в тестовой среде с тремя базами, но в реальной корпоративной сети на 200 рабочих станций способна парализовать вход в систему. Потратьте один день на настройку эталонного файла V8I — и забудьте о жалобах на долгий запуск и пропавшие базы.