Клиент-серверный режим 1С 8.3 для тестирования: SQL Express, порты и перенос из файловой базы

Клиент-серверный режим информационной базы 1С:Предприятие 8 с SQL Server нужен не только администраторам: если вы тестируете свои алгоритмы только в файловой базе, часть ошибок всплывёт уже у заказчика на сервере. Ниже - минимальный стенд под локальное тестирование: сервер 1С, СУБД и клиент по сети, без претензий на промышленный кластер и без веб-публикации.

Зачем отдельный стенд под клиент-сервер

metrics: Клиент-серверный режим 1С 8.3 для тестирования: SQL Express,

Файловый и клиент-серверный режимы для разработчика не взаимозаменяемы. В файловой базе код часто крутится там, где вы привыкли его видеть в конфигураторе, а на сервере тот же модуль выполняется в другом контексте: другая учётная запись процесса, другие права на каталоги, другие ограничения на COM и файловые операции.

Классический сюрприз - DCOM. Вызов Excel.Application на сервере идёт не от вашего интерактивного пользователя, а от учётной записи агента сервера 1С (часто USR1CV8). Excel может быть не установлен для этой учётной записи, или DCOM не настроен, и алгоритм, который «открывал книгу» в файловом режиме, на сервере падает с ошибкой создания СОМ-объекта.

Вторая зона - файлы через асинхронные методы платформы. Процедуры вроде НачатьПомещениеФайлаНаСервере и НачатьПолучениеФайлаССервера завязаны на то, где реально лежит файл и кто его читает. В файловом режиме граница размыта; в клиент-серверном легко перепутать клиентский и серверный путь и получить пустой двоичный данные или отказ в доступе.

Третья зона - программная СКД. Схему компоновки данных разумно собирать на сервере (&НаСервере или &НаСервереБезКонтекста), а на клиент передавать через ПоместитьВоВременноеХранилище и ПолучитьИзВременногоХранилища. Если генерацию схемы оставить на клиенте «как в прототипе», в серверном режиме отчёт может не построиться или построится с другими отборами.

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

Что строим и где границы инструкции

checklist: Клиент-серверный режим 1С 8.3 для тестирования: SQL Express,

Схема намеренно примитивная: один компьютер выступает сервером (служба 1С + SQL Server Express), второй (или тот же ПК для первого прогона) - клиент с тонким или толстым клиентом в одной подсети. Windows 10 Pro x64, учётная запись с правами администратора на обеих сторонах, обычная домашняя или офисная LAN.

Платформа: 1С:Предприятие 8.3, разрядность x86-64, версия из вашего проекта (в примерах ориентир 8.3.18 и новее). СУБД для статьи - Microsoft SQL Server Express 2019 или 2022 с Management Studio. Логика та же, что у старых гайдов на Express 2014: смешанная авторизация, логин sa при создании ИБ, флаг автосоздания базы в консоли кластера.

Если сознательно ставите PostgreSQL под 1С, в консоли администрирования указываете тип СУБД PostgreSQL, порт 5432 и учётную запись не sa, а пользователя PostgreSQL с правом CREATE DATABASE. Шаги службы 1С и перенос *.dt те же; меняются только параметры подключения к СУБД и правила брандмауэра для порта СУБД.

За рамками материала: публикация на IIS или Apache, веб-клиент, балансировка нескольких серверов, Always On, тонкая настройка производительности SQL. Только клиент-сервер для тестирования разработок.

На сервере после установки платформы полезно сразу понимать, где лежат служебные каталоги srvinfo, reg_* и logs, и куда положить файл *.dt перед загрузкой.

Сервер 1С: платформа, агент и USR1CV8

flow: Клиент-серверный режим 1С 8.3 для тестирования: SQL Express,

На машине-сервере запускаю установщик платформы 1С и отмечаю компонент «Сервер 1С:Предприятие» (и при необходимости «Консоль администрирования серверов 1С», если не ставится отдельно). Без серверного компонента не появятся служба «Агент сервера 1С:Предприятие» и рабочие процессы rphost.

На шаге про учётную запись установщик предлагает создать USR1CV8 и назначить её службе. Это нормальный выбор для «боевого» минимализма, но для тестов DCOM и доступа к локальным ресурсам USR1CV8 часто слишком бедная: не администратор, профиль может быть пустым, Office не виден.

После установки открываю сервисы.msc, нахожу «Агент сервера 1С:Предприятие», вкладка «Вход в систему». Для чистой проверки алгоритмов без возни с DCOM я иногда временно ставлю Local System или своего администратора; для проверки «как у заказчика с USR1CV8» оставляю USR1CV8 и уже под неё настраиваю COM и каталоги. Переключение учётной записи требует перезапуска службы.

Проверка: диспетчер задач, вкладка «Подробности». Должны появиться ragent.exe и при активности кластера rphost.exe. Если их нет, смотрю журнал службы и каталог логов сервера 1С (путь зависит от версии; обычно Program Files\1cv8\srvinfo и подкаталоги reg_*).

Когда алгоритм трогает Excel через COM на сервере, отдельно проверяю установку Office для той же учётной записи, что у службы, и настройку DCOM для компонента Excel (права запуска и активации). Для тестового стенда я честнее переношу такую логику на клиент (&НаКлиенте) или ищу серверную альтернативу без UI (выгрузка в табличный документ, OpenXML). Интерактивный COM на сервере в продуктиве редко оправдан, но воспроизвести его на стенде иногда нужно, чтобы увидеть ту же ошибку, что у заказчика.

SQL Server Express: смешанный режим и SSMS

Ставлю SQL Server Express 2019 или 2022 with Tools, экземпляр по умолчанию или именованный - главное запомнить имя для строки подключения. В мастере на шаге «Режим проверки подлинности» включаю «Смешанный режим» и задаю пароль для sa. Эти данные понадобятся в консоли 1CV8 Servers при создании информационной базы; без СQЛ-авторизации типовый гайд «только Windows» ломается на шаге создания БД.

Открываю SQL Server Management Studio, подключаюсь к (local) или.\SQLEXPRESS с аутентификацией SQL Server, логин sa. Успешное подключение - сигнал, что TCP и экземпляр живы. Если SSMS не коннектится, дальше бессмысленно идти в 1С: сначала SQL Browser, протокол TCP/IP в конфигураторе SQL и перезапуск службы SQL.

На тестовом стенде sa с простым паролем допустим. В бою 1С обычно работает под отдельным login SQL с минимальными правами на свою базу; для статьи явно: sa только для локального стенда, не для продуктива.

Убедиться, что экземпляр слушает нужный порт, помогает простой запрос в SSMS к системным представлениям (не путать с языком запросов 1С).

SELECT local_tcp_port
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

В колонке local_tcp_port для деfаулт-экземпляра чаще всего 1433; для именованного Express смотрю порт в диспетчере конфигурации SQL Server и использую его в строке подключения 1С.

Кластер 1С и информационная база на SQL

Консоль «1CV8 Servers» (Администрирование серверов 1С) опирается на регистрацию radmin.dll. В меню Пуск после установки платформы есть смд-файл регистрации внешней компоненты - запускаю от администратора один раз. Без этого консоль не откроется или будет ругаться на компоненту, хотя служба ragent уже работает.

В консоли создаю (или проверяю) центральный сервер: имя кластера для простейшего стенда совпадает с сетевым именем сервера Windows. Добавляю информационную базу: тип СУБД Microsoft SQL Server, сервер БД как в SSMS, база данных - новое имя латиницей, галочка «Создать базу данных в случае её отсутствия», СQЛ-аутентификация, sa и пароль с установки.

Имя базы в SQL и имя ИБ в кластере не обязаны совпадать посимвольно, но путаница потом мешает при ручном разборе в SSMS. Я задаю осмысленное имя вроде TestCS_erp.

После создания в SSMS в списке баз появляется новая база; в консоли 1С статус ИБ должен позволять запуск. Ошибки «не удалось создать базу» часто сводятся к правам sa, закрытому порту 1433 или неверному имени экземпляра.

Чтобы убедиться, что платформа действительно работает с SQL, а не с файловым каталогом, смотрю свойства информационной базы в консоли (тип СУБД, строка сервера БД) и отсутствие пути к 1Cv8.1CD на диске клиента.

Перенос из файловой базы через выгрузку DT

Цепочка переноса короткая, но каждый шаг завязан на предыдущий: без рабочей ИБ в кластере DT некуда загружать.

Исходные данные беру из файловой копии: конфигуратор, Администрирование - Выгрузить информационную базу, файл *.dt. На сервере в конфигураторе подключаюсь к новой серверной ИБ (список баз - имя кластера и имя ИБ), затем Загрузить информационную базу из *.dt.

Загрузка может занять время; по окончании платформа предложит обновить конфигурацию базы данных, если версия конфигурации требует этого. Я выполняю обновление сразу, иначе регламентные задания и часть метаданных не совпадут с ожиданиями.

После миграции проверяю регламентные задания (не висят ли отключёнными критичные для вашего теста), пользователей и права. Для стенда часто хватает одного администратора платформы; если тестируете RLS, заведите отдельного пользователя.

Контекст выполнения кода напоминаю себе так: клиентские процедуры не могут напрямую лезть в базу; серверные видят данные, но не UI. Вызов серверного метода с клиента - отдельный сетевой вызов платформы.

&НаКлиенте
Процедура СохранитьОтчётВФайл(Команда)
	АдресСхемы = ПодготовитьСхемуКомпоновкиНаСервере();
	СохранитьФайлНаКлиенте(АдресСхемы);
КонецПроцедуры

&НаСервере
Функция ПодготовитьСхемуКомпоновкиНаСервере()
	Схема = Новый СхемаКомпоновкиДанных;
	// заполнение схемы на сервере
	Возврат ПоместитьВоВременноеХранилище(Схема, УникальныйИдентификатор);
КонецФункции

Если Схему собрать в &НаКлиенте и передать «как объект» без временного хранилища, в клиент-сервере часто упираетесь в сериализацию и контекст. На стенде это хороший мини-тест после переноса DT.

Для проверки, что запросы идут в SQL, а не в локальный файл, в сеансе предприятия можно выполнить простой запрос к регистру или справочнику, который точно есть в вашей конфигурации после загрузки DT.

ВЫБРАТЬ ПЕРВЫЕ 10
	Пользователи.Ссылка КАК Ссылка,
	Пользователи.Наименование КАК Наименование
ИЗ
	Справочник.Пользователи КАК Пользователи
ГДЕ
	НЕ Пользователи.ПометкаУдаления

Если в вашей конфигурации нет справочника Пользователи, возьмите любой знакомый объект после загрузки DT; цель - убедиться, что сеанс серверный и данные читаются из СQЛ-базы, а не из каталога 1Cv8.1CD.

Сеть, брандмауэр, клиент и отладка

Клиент не «открывает папку базы», а обменивается с кластером по TCP на портах 1541 и 1560.

Клиентское подключение добавляю на машине клиента: запуск 1С:Предприятие, добавить, тип «На сервере 1С:Предприятие», имя кластера = сетевое имя сервера (не «localhost», если клиент на другом ПК), имя ИБ как в консоли. Для первого опыта достаточно тонкого клиента; толстый клиент тоже идёт через кластер, но тянет больше локальных компонент.

Брандмауэр Windows на сервере: разрешаю вход для портов SQL (1433 TCP для умолчанию; для Express иногда динамический порт из конфигуратора SQL; 1434 UDP для SQL Browser при именованных экземплярах) и портов 1С. Минимальный набор для одного рабочего процесса: 1541 TCP (агент), 1560 TCP (первый rphost; диапазон 1560-1591 закладываю, если процессов несколько). Полный перечень для кластера шире (1540 и др.); для домашнего стенда я открываю 1541 и 1560 и смотрю, исчезла ли ошибка подключения.

Типичный симптом закрытого порта: клиент долго «висит» на подключении, затем сообщение о недоступности сервера или общая ошибка кластера без деталей. На сервере в логах ragent и rphost в srvinfo появляются отказы или пусто при попытке с клиента. С telnet или Test-NetConnection на клиенте проверяю 1541 и 1433 до разборов в 1С.

Раздел «Вы в клиент-сервере, а не в файле»: в конфигураторе и предприятии в свойствах информационной базы указан сервер кластера, нет каталога файловой базы. В диспетчере задач на сервере при открытом сеансе растёт rphost.exe. В свойствах сеанса (если доступны в вашей версии) режим не файловый.

Отладка 8.3 в клиент-сервере: на сервере в консоли администрирования для кластера или ИБ включаю «Разрешить отладку» (формулировка зависит от версии консоли). На машине разработчика запускаю конфигуратор с параметром отладчика или подключаюсь к сеансу через Отладка - Подключиться к процессу; для тонкого клиента на другой машине использую запуск с ключом debugger у predpriyatie.exe по документации вашей версии платформы.

Если отладчик не цепляется, первым делом проверяю брандмауэр на портах отладки (диапазон задаётся платформой; для стенда проще временно разрешить конфигуратору и rphost вход с подсети клиента, чем гадать). Вторая причина - отладка запрещена в кластере или сеанс запущен без права отладки у пользователя.

После успешного подключения точки останова в &НаСервере срабатывают на сервере; в &НаКлиенте - на клиенте. Смешанный пошаговый проход как раз показывает, где ваш алгоритм ошибочно положил файл или COM.

Что забрать себе

• Свои алгоритмы имеет смысл гонять в клиент-серверном режиме на SQL Server Express (или PostgreSQL, если так решили), даже если файловая база уже есть: контекст сервера, USR1CV8 и порты меняют поведение.
• Три места, где я чаще всего терял время на стенде: смешанная СQЛ-авторизация и sa при создании ИБ, регистрация radmin.dll, брандмауэр 1541/1560 и 1433.
• После загрузки DT не забываю обновление конфигурации БД, проверку регламентных заданий и осознанный выбор учётной записи службы, если тестирую DCOM или файлы на сервере.