Администрирование · 13 мин
Как работать с базами данных в 1С
Как работать с базами данных в 1С: файловый и клиент-серверный режимы, создание и подключение базы, резервное копирование, права доступа и типичные ошибки.
База данных в 1С — это не абстрактный SQL-контейнер, а вся прикладная информация предприятия: справочники, документы, регистры, настройки и пользователи. От того, как организовано хранение и обслуживание этой базы, зависят скорость работы программы, сохранность данных и возможность восстановления после сбоя. Поэтому работать с базой нужно по понятным правилам, а не «как получится».
В 1С существует два принципиально разных режима хранения данных: файловый и клиент-серверный. В первом вся база — это один файл 1Cv8.1CD на диске или в сетевой папке, во втором данные хранит СУБД (MS SQL Server, PostgreSQL, Oracle), а платформа 1С обращается к ней через сервер приложений. Выбор режима определяет почти всё: способы резервного копирования, ограничения по числу пользователей и требования к оборудованию.
Важно понимать двойственность архитектуры: с одной стороны есть база данных на уровне хранения, с другой — конфигурация (прикладное решение), которая описывает структуру этих данных. Пользователь работает с данными через интерфейс конфигурации, разработчик — через конфигуратор, администратор — через инструменты СУБД и кластера серверов. Эти три роли часто путают, что приводит к ошибкам.
Файловый и клиент-серверный режимы: что выбрать
Файловый режим подходит для небольших коллективов — ориентировочно до 5–10 активных пользователей. База размещается в общей папке, пользователи подключаются к ней напрямую. Плюсы: простота, не нужен отдельный сервер и администратор СУБД. Минусы: при росте объёма данных и числа пользователей падает скорость, повышается риск повреждения файла при сбое сети или питания, а монопольные операции (например, обновление конфигурации) требуют выгнать всех пользователей.
Клиент-серверный режим используют, когда работают десятки и сотни пользователей, база велика или нужна высокая надёжность. Данные хранит СУБД, платформа 1С обращается к ней через сервер 1С:Предприятия. Это даёт параллельную работу без блокировок файла, штатные средства резервного копирования СУБД и возможность масштабирования. Цена вопроса — необходимость администрировать серверный стек: следить за местом на дисках, журналами транзакций, регламентными заданиями СУБД.
Сравнение вариантов
Подходит для 1–10 пользователей и небольших объёмов. Ограничение: чувствительность к сбоям сети и питания, снижение скорости при росте базы.
Подходит для десятков пользователей и больших объёмов. Ограничение: требует сервера, СУБД и регулярного администрирования.
Подходит, если нет своего сервера и администратора. Ограничение: зависимость от провайдера и доступа в интернет.
Создание и подключение информационной базы
Новую базу создают через стартер 1С (окно запуска со списком баз): кнопка «Добавить» → «Создание новой информационной базы». Дальше выбирают источник: из шаблона конфигурации (например, типовой «Бухгалтерии предприятия») или пустую базу без конфигурации. Для рабочего учёта почти всегда берут шаблон — пустая база нужна разработчикам для создания собственного решения с нуля.
При создании файловой базы указывают каталог на диске — платформа создаст там файл 1Cv8.1CD. При создании клиент-серверной базы задают имя сервера 1С, тип СУБД, имя базы данных и учётные данные для подключения к СУБД. Ошибки на этом этапе обычно связаны с правами: у пользователя СУБД должны быть права на создание базы, а сервер 1С — доступ к серверу СУБД по сети.
Подключение существующей базы выполняется той же кнопкой «Добавить», но с вариантом «Добавление в список существующей информационной базы». Для файловой указывают путь к каталогу, для серверной — параметры кластера и имя базы. Типичная ситуация: база лежит на новом сервере, а у пользователей остался старый путь — достаточно поправить параметры подключения в свойствах базы в списке.
- 1Установите шаблон конфигурации (дистрибутив типового решения), если он ещё не установлен.
- 2Откройте окно запуска 1С и нажмите «Добавить» → «Создание новой информационной базы».
- 3Выберите нужный шаблон из списка и задайте имя базы.
- 4Укажите каталог на локальном диске или в сетевой папке с достаточным объёмом свободного места.
- 5Запустите базу, выполните первоначальное заполнение и создайте пользователя с правами администратора.
Основные операции с данными внутри базы
Повседневная работа пользователя с базой — это ведение справочников (контрагенты, номенклатура, сотрудники), ввод и проведение документов, формирование отчётов. Введённый документ становится учётным фактом только после проведения: платформа записывает движения по регистрам, и эти данные попадают в отчёты. Если отчёт «не видит» документ — первым делом проверьте, проведён ли он и не помечен ли на удаление.
Массовые изменения данных — загрузка номенклатуры из файла, групповое изменение реквизитов — выполняют штатными обработками («Групповое изменение реквизитов», «Загрузка данных из табличного документа»). Перед любой массовой операцией делайте резервную копию: отменить групповое изменение в тысяче элементов штатными средствами нельзя.
Отдельный класс операций — служебные: пометка на удаление и удаление помеченных объектов, тестирование и исправление базы, пересчёт итогов. Удаление помеченных объектов выполняется монопольно и может занять много времени на большой базе. Тестирование и исправление (через конфигуратор) запускают только на копии или при отсутствии работающих пользователей и только после резервного копирования.
Резервное копирование и восстановление
Единственный надёжный способ защитить данные — регулярные копии, причём проверенные на восстановление. Для файловой базы есть два рабочих способа: выгрузка в файл .dt через конфигуратор («Администрирование» → «Выгрузить информационную базу») или копирование файла 1Cv8.1CD при отсутствии активных сеансов. Копировать файл, пока с базой работают пользователи, нельзя — копия может оказаться битой.
Для клиент-серверной базы основной инструмент — штатное резервное копирование СУБД: полные копии по расписанию и копии журналов транзакций для восстановления на момент времени. Выгрузка в .dt в клиент-серверном режиме тоже возможна, но на больших базах занимает часы и создаёт нагрузку, поэтому её используют как дополнительный способ или для переноса базы между серверами.
Копия, которую ни разу не восстанавливали, — это надежда, а не страховка. Раз в месяц или после изменения схемы копирования стоит развернуть свежую копию в тестовом каталоге и убедиться, что база открывается, отчёты строятся, ключевые документы на месте. Время восстановления тоже важно знать заранее: если база разворачивается шесть часов, это нужно учитывать в планах на случай аварии.
Как проверить качество резервного копирования
Копии создаются по расписанию и хранятся отдельно от рабочей базы
Копии лежат на том же диске, что и база, или создаются вручную «когда вспомнят»
Тестовое восстановление проходит успешно, база открывается и работает
Копия не разворачивается или при восстановлении появляются ошибки
В копии присутствуют данные за последние рабочие дни
В копии данные недельной или месячной давности при ежедневном регламенте
Права доступа и пользователи
Каждый сотрудник должен работать в базе под своей учётной записью — это базовое требование и для безопасности, и для разбора спорных ситуаций: по журналу регистрации видно, кто создал или изменил документ. Общие учётные записи вида «менеджер» делают журнал бесполезным и мешают разграничению прав.
Права назначаются через роли, определённые в конфигурации: полные права, права бухгалтера, менеджера по продажам и т. д. Принцип безопасной настройки прост: давать минимально необходимый набор прав и добавлять при необходимости, а не выдавать полные права «чтобы работало». Полные права оставляют одному-двум администраторам.
При увольнении сотрудника его учётную запись отключают, а не удаляют вместе с историей: данные, созданные этим пользователем, остаются, а вход под его именем становится невозможен. Периодически полезно просматривать список активных пользователей и сеансов — через «Администрирование» → «Активные пользователи» в типовых конфигурациях или консоль кластера для серверных баз.
Типичные проблемы и их решение
Самая частая жалоба — «база тормозит». Причины разные в зависимости от режима: в файловой базе чаще всего виноваты медленный диск, сетевое размещение файла, антивирус, проверяющий файл базы «на лету», или разросшийся объём. В клиент-серверной — нехватка памяти на сервере СУБД, фрагментированные индексы, тяжёлые запросы отчётов. Диагностику начинают с простого: проверить место на дисках, исключения антивируса и нагрузку на сервер.
Вторая типичная ситуация — ошибки блокировок: «Конфликт блокировок при выполнении транзакции». Она возникает, когда два пользователя одновременно изменяют связанные данные, или когда регламентное задание пересекается с работой пользователей. Разовая ошибка обычно решается повтором операции; регулярные конфликты — повод пересмотреть расписание регламентных заданий и порядок работы.
Третья группа — повреждение файловой базы после сбоя питания или сети: база не открывается, появляются ошибки формата потока. Порядок действий: не паниковать и не запускать всё подряд, а сначала скопировать повреждённый файл в сторону, затем восстановить из последней копии или выполнить тестирование и исправление на копии повреждённого файла. После восстановления стоит сверить итоги по ключевым отчётам с последними известными значениями.
Когда обращаться к специалисту
Часть задач вполне выполнима своими силами: создать базу из шаблона, настроить ежедневное копирование, завести пользователей, загрузить справочник из файла. Но есть границы, за которыми самостоятельные эксперименты обходятся дороже услуг специалиста.
К специалисту стоит обращаться при переходе с файлового режима на клиент-серверный, при повреждении базы без свежей копии, при подозрении на потерю данных, при настройке сложного разграничения прав и при регулярных ошибках СУБД. Также не стоит самостоятельно обновлять конфигурацию, если в неё вносились доработки, — объединение изменений требует опыта.
Как выбрать действие
Что важно запомнить
Выбирайте режим хранения под реальное число пользователей, делайте резервные копии по расписанию и периодически проверяйте их восстановлением, раздавайте права по принципу минимума, а любые служебные и массовые операции выполняйте только после создания копии. Эти четыре правила предотвращают большинство потерь данных в 1С.
Частые вопросы
Можно ли работать с базой 1С напрямую через SQL-запросы?
Технически к таблицам СУБД обратиться можно, но изменять данные напрямую категорически не рекомендуется: логика платформы (проведение, итоги, служебные таблицы) при этом нарушается, и база может стать несогласованной. Чтение для аналитики допустимо с пониманием структуры, запись — только средствами платформы 1С.
Чем выгрузка в .dt отличается от копирования файла базы?
Выгрузка в .dt создаёт логический снимок базы средствами платформы и подходит для переноса между режимами и версиями, но требует монопольного доступа и времени. Копирование файла 1Cv8.1CD быстрее, но корректно только при полностью закрытых сеансах. Для клиент-серверных баз основной способ — резервное копирование средствами СУБД.
Как перенести файловую базу на другой компьютер?
Завершите все сеансы, скопируйте каталог с файлом 1Cv8.1CD на новое место, затем в окне запуска 1С на новом компьютере добавьте существующую базу и укажите новый путь. Проверьте, что база открывается и отчёты формируются, прежде чем удалять старую копию.
Почему файл базы растёт, хотя данных вводится немного?
Файл 1Cv8.1CD не уменьшается сам при удалении объектов — освобождённое место внутри файла просто помечается как свободное. Также объём увеличивают журнал регистрации, хранилища присоединённых файлов и версии объектов. Сократить физический размер можно выгрузкой базы в .dt и загрузкой обратно в новую базу.
Нужно ли останавливать работу пользователей для обновления конфигурации?
Да, обновление конфигурации базы данных требует монопольного доступа: все сеансы должны быть завершены. В клиент-серверном режиме сеансы можно завершить принудительно через консоль кластера. Планируйте обновление на нерабочее время и делайте копию перед началом.
Что делать, если забыт пароль администратора базы?
Если в базе есть другой пользователь с полными правами, он может сбросить пароль через список пользователей. Если такого пользователя нет, самостоятельных штатных способов восстановления нет — потребуется специалист, который сможет восстановить доступ с использованием резервной копии или специальных методов. Чтобы не попадать в такую ситуацию, держите минимум две учётные записи с полными правами.