Переход с файлового варианта работы базы данных на клиент-серверный — это стандартный этап роста любой системы автоматизации. Однако для начинающего разработчика, работающего с классическими конфигурациями (такими как Управление торговлей 10.3), этот процесс может вызвать опасения. Основной вопрос заключается в том, нужно ли переписывать код под управляемые директивы и какие скрытые ошибки могут возникнуть при слиянии доработок с рабочей базой клиента. Разберем эту ситуацию подробно, проанализируем технические нюансы и составим пошаговый план безопасного перехода.
Для начала проясним важный момент: в конфигурациях на «обычных формах» (как в вашем случае с УТ 10.3) использование директив &НаКлиенте и &НаСервере не является обязательным и зачастую даже невозможно в рамках классического интерфейса. Эти конструкции относятся к «управляемому приложению». В «толстом клиенте» код по умолчанию имеет доступ ко многим ресурсам, но при переходе на серверную версию правила игры меняются.
Рассмотрим ситуацию: в файловой версии вся программа выполняется в одном процессе на компьютере пользователя. Когда вы переходите на сервер, код начинает разделяться: часть выполняется на стороне пользователя (клиент), а часть — на стороне сервера 1С (сервер). Рассмотрим подробнее, к каким последствиям это приводит.
Это одна из самых коварных ошибок, которая никогда не проявляется в файловом режиме, но моментально «роняет» систему на сервере. Выясним причину ее возникновения. При обмене данными между клиентским приложением и сервером 1С происходит процесс сериализации — превращение программного объекта в поток данных для передачи по сети.
Мутабельные значения (изменяемые объекты) — это такие типы данных, которые нельзя однозначно передать «как есть» между процессами. К ним относятся:
ТаблицаЗначенийДеревоЗначенийСправочникОбъект, ДокументОбъектЕсли в вашем коде процедура на сервере пытается вернуть клиенту ТаблицаЗначений напрямую (в качестве параметра или результата функции), серверная база выдаст критическую ошибку. Проанализируем пример кода, который будет работать в файловой базе, но упадет в серверной:
// В файловой базе это сработает, в серверной — нет
Процедура ОбработатьДанныеНаСервере(МояТаблица) Экспорт
// Какие-то действия с таблицей
КонецПроцедуры
Чтобы избежать этой проблемы, данные необходимо преобразовывать в неудаляемые/неизменяемые типы, такие как Массив (состоящий из структур) или Структура, либо использовать временное хранилище.
При переносе кода в клиент-серверный вариант критически важно проверить свойства общих модулей, в которых вы писали свои функции. Разберем основные флаги:
Предупреждение() или Вопрос().Проанализируем типичную ошибку: если ваш код обращается к общему модулю, у которого стоит галочка только «Клиент», а вы вызываете его из контекста проведения документа (который на сервере), система выдаст ошибку «Процедура или функция не определена». Всегда проверяйте, чтобы модули, содержащие бизнес-логику, имели флаг «Сервер».
Выясним, почему внешние файлы (Excel, картинки, логи) могут перестать открываться. В файловой базе 1С работает от имени текущего пользователя Windows. В серверной версии код, исполняемый на стороне сервера, работает от имени специальной учетной записи (обычно это USR1CV8 или 1CV8).
Посмотрим на типичные проблемы:
C: его компьютера.\\Server\Folder) должны быть доступны для учетной записи, под которой запущен Агент сервера 1С.Если вы разрабатывали код на 32-битной версии 1С, а клиент использует 64-битный сервер (что сейчас является стандартом), могут возникнуть проблемы с внешними компонентами (DLL). Разберем ситуацию: драйвер сканера штрих-кода или компонента печати этикеток, написанная под 32 бита, просто не загрузится в 64-битном серверном процессе. В этом случае код нужно выносить строго на сторону клиента, где приложение остается 32-битным.
Проанализируем работу с объектом МенеджерВременныхТаблиц. В клиент-серверном режиме менеджер временных таблиц живет строго в рамках одного соединения. Если ваша логика подразумевает создание временной таблицы в одном модуле и попытку прочитать ее в другом через некоторое время (при этом происходит разрыв контекста между клиентом и сервером), таблица будет пуста. Старайтесь завершать работу с временными таблицами в рамках одного вызова сервера.
Чтобы не бояться «посыпавшихся ошибок» при слиянии вашей разработки с рабочей базой клиента, выполним следующие шаги:
Сервер, Толстый клиент (обычное приложение), Внешнее соединение. Это позволит выявить 90% проблем с недоступными функциями до момента загрузки в базу.Журнал регистрации. Многие ошибки сервера не выводятся пользователю на экран в виде привычных окон, а просто тихо записываются в журнал или прерывают транзакцию.Помните, что для УТ 10.3 переход на сервер обычно проходит гладко, если вы не увлекались передачей огромных таблиц значений между общими модулями. Главное — следить за тем, чтобы серверный код не пытался вызвать диалоговые окна (интерактивные действия) и имел права на доступ к нужным файлам.