Многие пользователи файловых баз 1С, опубликованных на веб-серверах (IIS или Apache), столкнулись с неприятной ситуацией: при попытке вывести на печать счет на оплату для физического лица или ИП, программа «намертво» зависает. Более того, это действие часто приводит к остановке работы всех остальных пользователей, подключенных к этой же базе. Давайте разберемся, почему это происходит и как исправить ситуацию.
Проблема кроется в обновлении конфигурации «Бухгалтерия предприятия» 3.0 (начиная с релиза 3.0.141.39). Разработчики заменили внутреннюю компоненту для генерации штрихкодов и QR-кодов. Ранее использовалась BarcodeLib.ExtLibrary, а теперь — AddIn.Barcode. При работе через веб-сервер попытка инициализировать эту новую компоненту вызывает критический сбой в рабочем процессе веб-сервера.
Так как веб-сервер работает как единый процесс, ошибка инициализации AddIn.Barcode приводит к блокировке потоков для всех пользователей. Именно поэтому другие сотрудники не могут зайти в базу или продолжить работу, пока вы не перезапустите веб-сервер или не дождетесь завершения зависшего процесса.
Фирма «1С» оперативно реагирует на подобные ошибки, выпуская исправительные патчи (исправления). Это самый правильный и безопасный путь решения проблемы.
Бухгалтерия предприятия 3.0 (например, патч EF_00_00563978).AddIn.Barcode будет устранена, и печать счетов заработает в штатном режиме как на 32-битной, так и на 64-битной платформе.Если по какой-то причине вы не можете оперативно установить патч, можно временно отключить отображение QR-кода в печатной форме счета. Это позволит избежать зависания процесса, так как система перестанет обращаться к проблемной компоненте при формировании документа.
Рассмотрим, как это сделать через настройки макета:
РисунокQR и РисунокQRЛоготип.РисунокQR1 и РисунокQRЛоготип1.В случае, если в вашей базе работают одновременно много пользователей (10 и более человек) в файловом режиме через веб-сервер, любая ошибка одного из них может негативно влиять на остальных. Чтобы минимизировать риски, мы рекомендуем использовать архитектуру с разделением публикаций.
Вы можете опубликовать базу на веб-сервере несколько раз, используя разные виртуальные каталоги и порты. Это приведет к тому, что для каждой публикации будет создан свой отдельный рабочий процесс (w3wp.exe для IIS), и зависание одного процесса не «положит» работу всей компании.
Важное замечание: При реализации этого метода убедитесь, что на сервере достаточно оперативной памяти. Каждая публикация 1С при запуске потребляет значительные ресурсы для хранения кэша метаданных (в среднем около 1 ГБ на один рабочий процесс). Постоянный мониторинг потребления ОЗУ поможет избежать проблем с быстродействием системы.
Подводя итог, можно сказать, что ситуация с зависанием — это следствие конфликта программных компонентов, который уже успешно лечится разработчиком. Мы настоятельно советуем не прибегать к радикальным мерам (откату платформы или смене разрядности), а сосредоточиться на установке актуальных патчей, так как это гарантирует стабильность системы в будущем.