Что-то довольно часто в последнее время на рабочих местах менеджеров при работе с 1С (релиз: 8.2.19.121)
стало появляться вот такая вот ошибка:
Ошибка SDBL:
Ожидается выражение (pos=422)
Ошибка появляется не в момент подключения к базе, а в любой момент при вызове различных действий. Как пояснил коллега (Программист 1С) — это вызвано тем, что в профиле пользователя клиент 1с плодит так называемые временные файлы. Данные временные файлы (своего рода кэширование) включают в себя статичную информацию сохраняемую на компьютере пользователя, что бы не запрашивать их с сервера при каждом подключении/обращении. В виду этого платформа 1С не всегда корректно взаимодействует с данными временными файлами
Но вот когда к тебе обращаются с вопросом — а что у нас 1С на работает, уже честно говоря достало отвечать, что работа программы 1С не твоя задача, мне как системному администратору, ну такой я по натуре, лучше все же разобрать как устранить данную ошибку на местах пользователей.
Вот к примеру на одной рабочей станции (Windows 7 Professional SP1: hostname: hp-work, учетная запись hp-work) по адресу:
%systemdrive%\Users\hp-work\AppData\Local\1C\1Cv83\{UUID}\{UUID}\vrs-cache
Всего файлов по этому адресу аж: 196895
А содержимое данного каталога — кэш файлы клиентской части 1С.
Ранее на сколько я вижу по своим записям (я веду отчет за каждый день, что сделано), а именно 22.04.2016 я уже удалял файлы кеша 1С, теперь 04.05.2016 на системе hp-work опять заканчивается место (ну может не заканчивается, но все уменьшается):
Сейчас свободно 357Gb из 465Gb
Чтобы каждый раз не обращаться к данному компьютеру и чтобы хост на алармил почем зря на сервере мониторинга Zabbix написал вот такой вот скрипт (по очистке файлов кеша), который поставил в планировщик на запуск каждую неделю по восресеньям.
C:\script\clear_cache.bat
echo off
rem clear 1C cashe folder
for /d %%i in ("%LOCALAPPDATA%\1C\1Cv82\* | findstr /vile ".1CD" ".1CL"") do rmdir /S /Q "%%i"
Создал задание на запуск в 06 утра каждую неделю по воскресеньям:
На заметку:
- *.1CL → файлы для блокировок
- *.1CD → файл базы данных содерщий внутри своего рода файловую систему, включающую в себя так называемые внутренние файлы
На заметку: от 15.06.2017
Данный скрипт не совсем точно работает хотя и работает. Вот более свежий вариант:
echo off
rem clear 1C cache folder
taskkill /F /FI "USERNAME eq %username%" /im 1cv8.exe
taskkill /F /FI "USERNAME eq %username%" /im 1cv8c.exe
DEL /F /S /Q /A %LOCALAPPDATA%\1C\1Cv82\*cache*
DEL /F /S /Q /A %APPDATA%\1C\1Cv82\*cache*
На терминальном сервере нужно закинуть его в AutoRun профиля пользователя: %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup и после того, как пользователь будет подключаться по RDP к терминальному серверу будет выполняться данный скрипт и очищать кеш 1С из-за которого встречаются многочисленные ошибки, как на пример выше в текущей заметке.
Либо же кэш для всего терминального сервера чиститься одной командой из под PowerShell с правами Администратора:
Get-ChildItem "С:\Users\*\AppData\Local\1C\1Cv82\*","С:\Users\*\AppData\Roaming\1C\1Cv82\*" | Where {$_.Name -as [guid]} |Remove-Item -Force -Recurse
Открыв оснастку управления заданиями, вижу свое созданное через правый клик по нему запускаю его и оно успешно отрабатывает. Как проверить, а действительно ли успешно, в колонке «Результат последнего запуска» должно быть «Операция успешно завершена. (0x0)» и ни какие другие сообщения.
После отработки скрипта место на системном диске: 440Gb свободно из 465Gb, 25Gb занимает система и файлы настроек других программ.
Данными шагами выше, я предотравтил уведомление в будущем от сервера Мониторинга об уменьшении свободного места на системном разделе, да и лично на обслуживаемых рабочих станциях пользователей убрал ошибку связанную с переполнением временных файлов. Пока мне этого достаточно, а пока я прощаюсь с Вами, до новых заметок — с уважением, автор блога — ekzorchik.