1с сбросить повторное использование

Обновлено: 07.07.2024

В статье рассказывается что такое Кэш 1С и как его можно самостоятельно очистить несколькими способами. В конце публикации расположена подробная видеоинструкция.

Что же такое Кэш вообщем и Кэш 1С в частности. В переводе с английского cashe означает тайник либо хранилище. Впервые данный термин в компьютерном слэнге был использован в 1967 году во время подготовки стать для журнала «IBM Systems Jornal» (ссылка на статью в векипедии) . Векипедия дает данному термину следующее определение Кэш – промежуточный буфер с быстрым доступом, содержащий информацию, которая может быть запрошена с наибольшей вероятностью. Процесс кэширования используется как при работе, самого компьютера, так и при работе отдельных программ, 1С не является исключением. Кэшом 1С называется область на компьютере, куда платформа в процессе работы записывает наиболее часто используемую информацию для более быстрого доступа к ней, это может быть служебная информация пользователей, список отборов, шрифтов, расположение окон. При возникновении каких-либо сбоев Кэш начинает обрабатываться неправильно, и программа начинает работать некорректно. Это может произойти в случае аварийного завершение работы программы, например при отключении питания компьютера, динамического обновления программы, обновления без завершения работы пользователей и др.

В случае возникновения таких сбоев необходимо произвести чистку Кэша 1с, данную процедуру рекомендуется делать не только при возникновении сбоев, но и в рамках регламентного обслуживания программы, ведь часто в КЭШе хранятся данные, которые программа уже не использует и они только занимают место на компьютере, замедляя при этом работу 1с.

Существует несколько способов чистки Кэша 1С, давайте разберем подробно каждый из них

Первый и самый простой это удалить из списка базу, запомнив и сохранив ее путь и добавить ее туда снова. Сохранить путь проще всего следующим образом: выделить базу в списке, нажать на кнопку «изменить», откроется окно редактирование информационной базы, в котором нам нужно выделить строчку, которая находится в поле «каталог информационной базы». Кликнуть по ней правой кнопкой мыши и нажать копировать, записывать тем самым путь к базе в буфер обмена вашей операционной системы, его можно либо оставить там, до момента добавления базы, либо сохранить в любой текстовый редактор, например в Microsoft Word. И нажать на кнопку отмена, закрыв тем самым окно редактирование информационной базы

После этого в окне конфигурации жмем на кнопку «Удалить» и утвердительно отвечаем на вопрос программы

Базу из списке мы удалили, теперь необходимо ее добавить, для этого в окне платформы жмем на кнопку «Добавить», устанавливаем переключатель в «Добавление в список существующей информационной базы» и жмем «Далее»

В открывшемся окне в поле «Укажите название информационной базы» руками пишем название нашей базы, в поле «Каталог информационной базы» копируем пусть нашей базы, который мы сохранили на предыдущем шаге и жмем «Далее»

На следующем шаге оставляем все по умолчанию и жмем «Готово»

База в список у нас добавлена, Кэш для нее очищен

Данный способ хоть и является самым простым, но имеет ряд недостатков, во-первых при нем файлы Кэша не удаляются с компьютера, а лишь отвязываются от базы при ее удалении, оставаясь в компьютере и засоряя тем самым его память, во-вторых если в Вашем списке не одна база а несколько, такую процедуру придется проделывать для каждой базы. Этим способом рекомендуется пользоваться в тех случаях, когда необходимо быстро восстановить работу базы и нет времени разбираться или ждать программиста. Например, программа дала сбой, а Ваш программист в данный момент занят и не может Вам помочь и чтобы не останавливать работу, Вы чистите Кэш этим способом, но в дальнейшем будет необходимо провести его чистку другим способов с удалением файлов Кэша, о котором я рассажу далее.

Второй способ это вручную удалить файлы Кэша с компьютера. Чтобы это сделать, для начала нужно определить их местонахождение. Кэш 1C в Windows хранится в следующих папка профиля пользователя это Roaming и Loсal. Данные папки расположены в пути: C:\Users\ИмяПользователя\AppData. Причем папка AppData по умолчанию скрыта. Попасть в нее можно двумя способами: это либо включить отображение скрытых папок, перейдя в Панель управления→Параметры папок→Вкладка «Вид»→Показывать скрытые файлы, папки и диски

Либо в проводнике вручную, после имени пользователя написать строчку \AppData и нажать на клавиатуре Enter

Либо если мы вдруг не знаем имя пользователя в проводнике можно написать следующую строчку: %userprofile%\AppData, нажать Enter и мы также попадем в эту папку

Попав в папку AppData, поочередно заходим в папки Local и Roaming и переходим в каждой из них в папку 1С, а в ней в 1Cv8 и если есть 1Сv82 то в нее тоже

В этих папках (1cV8, 1Cv82) мы видим множество папок с непонятным называнием, это и есть Кэш 1С. Все эти папки необходимо выделить и удалить, обязательно закрыв перед этим 1С, удалять можно смело, никакие данные из Вашей базы при этом не пострадают, а все необходимые папки платформа вновь создаст при очередном запуске

Данный способ является самым эффективным, но немного трудоемким. Его можно упросить, создав специальный файл, который будет проделывать все эти процедуры автоматически, вам лишь необходимо будет запустить его под именем администратора. Это файл будет иметь расширение.bat, в народе такие файлы называется «батник». Создать его можно следующим образом, открываем блокнот Windows и пишем в нем следующие команды:

Далее выбираем Файл→Сохранить как→выбираем место куда сохраняем, пишем название файла (например «cashe») и в названии меняем расширение с .txt на .bat, должно получиться как на картинке ниже, и жмем сохранить

Если вдруг не получается создать такой файл или Вам лень это делать, но можете скачать его готовый по следующей ссылке . Данный способ чистки Кэша 1С является самым простым, не требует никаких специальных знаний и навыков и выполняется за считанные секунды. Вам лишь необходимо запустить данный файл

И в заключении расскажу еще об одном способе очистки Кеша 1С - это установить дополнительный параметр запуска информационной базы. У данного способа есть свои плюсы и минусы, к плюсам я бы отнес, то, что Кэш очищается при каждом запуске 1С, к минусам – снижение общей производительности 1С. Еще отмечу, что данный способ подходит только для режима запуска Тонкий клиент. Данным способ рекомендуется использовать, тогда, когда ошибки базы связанные с Кэшем появляются систематически. Чтобы выставить данный параметр запуска, необходимо в окне платформы выбрать нужную информационную базу, нажать на кнопку «Изменить», в открывшемся окне ничего не меняя нажать «Далее»

Откроется окно редактирования информационной базы, где в дополнительных параметрах запусках необходимо написать строчку /ClearCache и кликнуть «Готово»

Обращу внимание, что после очистки Кэша Ваша база будет запускаться немного дольше обычного, т.к. программа будет создавать необходимые ей для работы временные файлы, но это только в первый раз после чистки, следующие разы запуск будет проходить быстрее. Также список пользователей базы (при их наличии) после очистки Кэша будет пуст, нужно будет выбрать нужного пользователя повторно

Если остались вопросы, можете задать их в комментариях, если же не хотите тратить свое время и доверить чистку Кэша 1С профессионалам, можете написать нам через форму обратной связи или позвонить по телефону который указан на сайте. будет рады Вам помочь.

Про повторное использование значений в рамках одного сеанса сказано уже достаточно. Давайте подумаем, как сделать то же самое, но глобально для ИБ в рамках всех сеансов. Спойлер: без вэб-сервера ничего не получится.

Upd: Внимание! Приведенный метод не является универсальным инструментом на все случаи жизни и имеет существенные ограничения. Прежде чем пилить код - обязательно читайте главу "Update: Потокобезопасность"

В чем проблема

Банальная инициализация параметров какого-то длительного фонового действия может занимать по нескольку секунд. А если это действие распараллелить - то с ростом производительности за счет многопоточной обработки - мы получим рост издержек на инициализацию параметров. Даже в пользовательских сеансах встречаются операции а-ля получения каких-то значений по-умолчанию, продолжающихся достаточно длительное время. Особой проблемы в рамках одного сеанса это как правило не представляет, но если 200 сеансов "долбят" базу данных одними и теми-же вопросами - это уже становится ощутимо.

Согласитесь, было бы здорово прочитать, например, параметры обмена данными один раз и использовать их дальше из оперативной памяти. В общем то такое уже встречается сплошь и рядом: в типовой УТ наверно сотня модулей с повторным использованием возвращаемых значений. Но есть проблема: все это работает только в рамках одного сеанса и у нас нет средства для передачи данных между сеансами (кроме разве что базы данных, но ее использование в этом качестве само по себе является анти-паттерном)

Решение

Схематично все это можно изобразить так:

Таким образом, мы как-бы "заворачиваем" вызовы из разных сеансов в один посредством REST сервиса, а в нем уже используем штатную функциональность модулей с повторным использованием возвращаемых значений.

Детали

Далее, варианты могут быть разными, вы можете писать какие-то специфичные функции установки и чтения параметров, но в случае написания универсальной процедуры, "оборачивающей" любую процедуру в повторно-используемую оболочку - получится следующее.

Здесь параметры соединение введены хардкодом, что как бы не очень хорошо, но если мы будем делать все по-правильному и читать их каждый раз из БД - эффект от повторного использования возвращаемых значений может быть существенно снижен.

Функции повторно-используемого модуля:

Подводные камни

Во-первых у этого метода есть ограничение снизу, некий "порог вхождения", который обусловлен существенными издержками на инициализацию общего сеанса и обращение "завернутое" через сетевые интерфейсы:

Первый вызов (в рамках которого происходит инициализация общего сеанса) в моем случае длится около 1 секунды. Этот параметр зависит от того, что у вас за конфа. У меня УТ 11.3.
Последующие вызовы, которые не инициализируют сеанс, а обращаются к уже готовому, занимают 0,015 - 0,02с, что вполне неплохо (это только время самой сетевой транзакции, если будет выполняться трехэтажный запрос - реальное время будет больше). Но я подозреваю, что тут все сильно зависит от сетевой архитектуры.

Здесь важно обратить внимание: инициализация длинной в 1 секунду будет проходить только один раз для всех возможных методов и наборов их значений, а не для каждого нового метода/значения.

Во-вторых у этого метода есть ограничение сверху, некий "потолок использования", который обусловлен размером оперативной памяти, которую вы готовы выделить под кэширование значений. Хотя, здесь невозможно не заметить, что если вы будете кэшировать эти данные традиционным способом, через повторноиспользуемый модуль для каждого сеанса - это займет памяти больше, кратно количеству сеансов, поэтому здесь есть как ограничение так и простор для экономии.

Дополнительные возможности

В рассмотренном случае, механизм повторного использования сеанса REST сервиса используется для получения функциональности повторного использования возвращаемых значений между сеансами, но это не единственная возможность. Видится возможным использовать этот механизм для организации других видов межсеансового взаимодействия, например:

передача данных между сеансами
хранение актуальных состояний и управление общим оборудованием, например, одним фискальником на несколько рабочих мест
управление соединением с другой ИБ (иметь COM-коннект в одном сеансе и использовать его из остальных)

И не стоит забывать, что все это будет работать только в версии 8.3.9 и выше. Удачи!

Update: Потокобезопасность

Комментарий Юрия Дешина подтолкнул меня к, как теперь кажется, очевидной мысли: заворачивание вызова нескольких сеансов в один, при некоторых обстоятельствах может привести к образованию очереди и массовому отказу в обслуживании вызовов. Так, пока сеанс Х выполняет какие-то вычисления, "заказанные" сеансом 1, сеанс 2 не сможет получить никакие данные (в том числе ранее закэшированные) от сеанса Х. При этом сеанс 2 будет "висеть", пока не будет достигнут тайм-аут (параметр poolTimeout в файле default.vrd), по достижении тайм-аута будет возвращен ответ 500.

В общем, как обычно, когда кто-то встает и спрашивает "а что там с потокобезопастностью?" - все становится сильно сложнее чем было до этого. Но это не значит, что задавать такие вопросы не нужно.

Что же нам со всем этим делать?

Ну во-первых, очень осторожно пользуйтесь вызовом такой процедуры в обработке проведения или внутри какой-либо другой транзакции записи.

Во-вторых, можно наметить следующие пути снижения рисков образования очереди в высоконагруженных системах:

Не использовать универсальных обработчиков, которые отвечают сразу за все (например такие, как описано выше). Т.е. если сервис будет отвечать и за расчет себестоимости и за соединение с соседней базой по COM - неизбежно будут возникать ситуации, когда мы не можем подключиться к соседней базе, потому что считаем себестоимость в этой (я утрирую, но мысль думаю понятна). Однако, если мы примем концепцию типа "одно значение - один сервис", то все будет логично: пока значения нет - все сеансы сидят и ждут когда оно появится. Появилось значение - раздали его всем.
Увеличивать число сеансов, раздающих значения. (параметр poolSize в файле default.vrd). Это экстенсивный путь, но до какой-то степени его можно считать рабочим, поскольку такое решение позволит избежать завешивания: при занятости одного сеанса - платформа автоматически переключит вызов на второй, третий, пятый и т.д., но в этом случае значение вычисленное в сеансе Х1 не будет доступно в сеансе и Х2 и будет вычисляться там заново. Можно думать об этом примерно так: все значения кэшируются в сеансе Х1, но он может быть недоступен, в этом случае вызов будет обработан сеансом Х2 (Х3. Хn), но значение будет вычислено заново.
Городить более сложные схемы взаимодействия с кэширующими сеансами, при которых использование сервиса сильно усложнится, но и вероятность получить отказ будет минимальной. Например такую:

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

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

Часто нам приходится по ходу исполнения программы получать значения, которые хранятся в базе данных и не меняются годами. Яркий пример - значения констант. Отчасти, можно причислить сюда же поиск элемента справочника или узла плана обмена по коду, получение значений реквизитов объектов по ссылке.

Не думая, "на лету" такие задачи решаются конструкциями вида:

В результате, каждый раз когда выполняется этот код - происходит "дерганье" базы данных.

Программисты более щепетильно относящиеся к своему коду, выполняют один запрос к базе данных, кэшируя все данные которые им понадобятся, однако такой подход не всегда приводит к желаемой разгрузке БД:

Цикл выполнения кода может быть неявным (например, групповое перепроведение документов)
Получить строгий набор данных (не больше и не меньше), которые потребуются позже, иногда затруднительно или вовсе невозможно.
Кэшированные значения требуется использовать в разных вызовах/формах

Модуль с повторным использованием возвращаемых значений

Для решения описанных проблем в платформе есть модули с повторным использованием возвращаемых значений. Фактически, это обычный общий модуль (клиентский или серверный), в котором Повторное использование возвращаемых значений установлено в "На время вызова" или "На время сеанса". В самом модуле процедуры и функции описываются как обычно.

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

Возвращаемые значения, естественно, кэшируются в разрезе значений переданных параметров, т.е. при выполнении кода

, оба вызова действительно приведут к выполнению соответствующей процедуры и вернут разные ссылки, а при последующих попытках получить узел с кодом 0001 или 0002 - будут возвращаться соответствующие узлы без вызова процедуры и, как следствие, базы данных.

Значения кэшируются отдельно для каждого сеанса на клиенте или сервере (в зависимости от того клиентский или серверный модуль). Т.е. если есть особенности настройки прав доступа или другой зависимости полученного значения от текущего пользователя - все отработает корректно.

Чего делать нельзя

Есть одно ограничение. В качестве параметров функций можно указывать только простые типы. Неопределено, Null, Булево, Дата, Строка, Число, Ссылка. Никаких структур, таблиц значений, объектов и т.п. Если вы попытаетесь передать в качестве параметра, например, структуру - все отработает, но о повторном использовании полученного значения можете забыть.

Возвращаемое значение при этом может быть любого типа.

Также, стоит обращать внимание на размер данных которые вы кэшируете. Всю память сервера вы забьете вряд ли, но помнить о том, что ресурсы не бесконечны стоит.

Баг или фича от 1С

Интересное свойство есть у повторно используемых значений. Баг это или фича непонятно, но знать о нем не помешет. Если выполнить код следующего характера:

, то в ЗначениеСтруктура2.Наименование будет лежать именно "Новое наименование". В принципе, это можно использовать для обновления значений, реально измененных в БД, но когда прикроют и прикроют ли лавочку - непонятно. При разработке типовых решений так делать запрещено.

Что делать при изменении закэшированных данных

Есть всего лишь один "легитимный" метод обработать ситуацию с изменением закэшированного значения в базе данных. Это метод ОбновитьПовторноИспользуемыеЗначения(). Будут сброшены значения всех функций по всем параметрам всех модулей. Обновить по конкретным значениям параметров / функциям / модулям нельзя.

Соответственно, из-за такого волюнтаристского подхода, пользоваться этой функцией необходимо крайне осмотрительно: вся система после его использования какое-то время будет работать существенно медленнее.

Посягаем на святое: пишем запрос в цикле

Кроме очевидных вариантов использования функций с повторным использованием возвращаемых значений, есть немало интересных, универсальных, нестандартных подходов, среди которых:

Написание универсальных процедур, возвращающих реквизиты произвольных ссылок (есть в БСП)
Написание процедур, возвращающих значения констант по имени константы (есть в большинстве типовых)
Возврат "чуть большего" объема данных, чем необходимо ради уменьшения количества вызовов (напр. если требуется получить курсы сразу нескольких валют, имеет смысл вызывать функцию по дате без отбора валюты, получить курсы всех валют и далее "разбираться на месте" какая из валют в настоящий момент нужна)
Написание процедуры, выполняющей запрос с кэшированием результата (входящими параметрами при этом будут текст запроса и пара-тройка имен и значений параметров)

Но есть еще один подход, на котором я хочу остановиться подробно. Это использование функции, содержащей вызов БД, с повторным использованием возвращаемого значения в цикле. Т.е. фактически это запрос в цикле. Вообще, нас учили так не делать, но бывают случаи, когда такое построение кода приведет к лучшей производительности, если:

Количество различных значений входящих параметров, которые встретятся внутри цикла небольшое и подавляющее большинство сочетаний с высокой долей вероятности было получено ранее в этом сеансе.
Заранее получить строгий набор сочетаний значений входящих параметров, которые встретятся в цикле затруднительно, а получение значений для всех возможных сочетаний значений входящих параметров приведет к считыванию большого объема данных из БД

Как видите формулировки не точные и больше похожи на напутствия, чем на правила. Поэтому всегда держите в голове контекст, оценивайте текущую картину, обдумывайте условия в которых будет работать ваш код.

Часто, при использовании динамического обновления конфигурации, у пользователей забивается кэш и программма не работает так, как надо. Проблема устраняется путем чистки пользовательского кэша. Но основновная загвоздка в том, что не возможно определить у какого пользователя (особенно если их больше 100) кэшированные модули соотвествуют текущей версии конфигурации, а у какого нет. Программист понимает это только тогда, когда у пользователя возникла ошибка и он присылает в отдел 1С письмо с руганью, принт-скринами и матами.

Подумав, как можно очищать кэш автоматом, было решено вызывать всем известный скрипт очистки кэша непосредственно из 1С.

В типовых конфигурациях уже предусмотрен обработчик оповещения, который проверяет не изменена ли конфигурация динамически. Если изменена, то пользователю предлагается перезапустить 1С, для того чтобы изменения вступли в силу.

Суть метода в том, чтобы при завершении работы проверить изменена ли конфигурация динамически еще раз, собрать скрипт, записать его и вызвать в момент закрытия программы. Скрипт сначала засыпает на 5 секунд, ожидая, пока закроется процесс 1С. После этого, смотрит есть ли запущенные процессы 1С, если есть, то убивает их. Затем, удаляет папки кэша и, в случае, если пользователь выбрал перезапуск сеанса, перезапускает 1С.

Т.к. мы пока не написали ничего на управляемом приложении, все описанное ниже, предназначено только для обычного.

В модуле обычного приложения есть процедура ОбработчикОповещения(), в ней периодически вызывается еще одна процедура ОбработчикОжиданияПроверкиДинамическогоИзмененияИБ ()

// Проверяет в конфигурации ИБ наличие изменений появившихся после старта сеанса
//
Процедура ОбработчикОжиданияПроверкиДинамическогоИзмененияИБ () Экспорт

// Если в конфигурации после старта текущего сеанса что-то изменилось
Если КонфигурацияБазыДанныхИзмененаДинамически () Тогда

// Завершим проверку обновления
ЗавершитьПроверкуДинамическогоОбновленияИБ ();

/ / Спросим пользователя о его желании перезапустить сеанс
ТекстВопроса = "В конфигурацию ИБ внесены изменения." + Символы.ПС +
"Для работы с ними рекомендуется перезапустить программу." + Символы.ПС +
"Перезапустить?" ;
РезультатВопроса = Вопрос ( ТекстВопроса , РежимДиалогаВопрос.ДаНет );

// Если пользователь не хочет перезапускать сеанс
Если РезультатВопроса = КодВозвратаДиалога.Нет Тогда
// Запустим проверку обновления опять
НачатьПроверкуДинамическогоОбновленияИБ ();
Возврат;
КонецЕсли ;

глЗначениеПеременнойУстановить ( " глПерезапускатьСеансРаботыСПрограммой " , Истина) ;

// Попробуем перезапустить
ПерезапуститьСеансРаботыСПрограммой ();

// Процедура перезапуска сеанса работы с программой
Процедура ПерезапуститьСеансРаботыСПрограммой () Экспорт
глЗначениеПеременнойУстановить ( "глЗапрашиватьПодтверждениеПриЗакрытии" , Ложь) ;

ЗавершитьРаботуСистемы (Истина);
КонецПроцедуры

Далее в модуле обычного приложения в процедуре ПриЗавершенииРаботыСистемы() необходимо прописать следующий код

Если КонфигурацияБазыДанныхИзмененаДинамически () Тогда

// у всех кроме программистов, т.к. у нас слишком часто открыты как рабочие базы так и конфигуратор.
Если НЕ РольДоступна ( "Администрирование" ) Тогда
ОчиститьКэшИПерезапуститьПрограмму ();
КонецЕсли;
КонецЕсли;

Процедура ОчиститьКэшИПерезапуститьПрограмму() находится в глобальном модуле.

// Процедура создает и запускает vbs файл, который производит очистку кэша.
// 1С и презапускает программу
//
Процедура ОчиститьКэшИПерезапуститьПрограмму () Экспорт

СкриптФайл = Новый ТекстовыйДокумент ;

СтрокаСоединенияСБД = СтрокаСоединенияИнформационнойБазы ();
СтрокаЗапускаПрограммы = КаталогПрограммы ();

ПутьКФайлуСкрипта = КаталогВременныхФайлов () + "CacheCleaning.vbs" ;
ПутьКФайлу1С = СтрокаЗапускаПрограммы + "1cv8.exe" ;

ИмяСервера = "" ;
ИмяБазы = "" ;
Путь = "" ;
КомандаЗапуска = "" ;

// Если пользователь не хочет перезапускать сеанс 1С, то после выполнения скрипта ничего не делаем.

Если Не глЗначениеПеременной ( "глПерезапускатьСеансРаботыСПрограммой" ) Тогда
КомандаЗапуска = "" ;
КонецЕсли;

Попытка
СкриптФайл . Записать ( ПутьКФайлуСкрипта , КодировкаТекста . Системная );
ЗапуститьПриложение ( ПутьКФайлуСкрипта );
Исключение

Ну вот как-то так.

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

Развитие темы.

Я тут подумал как развитие данной темы можно сделать следующее:

Создать регистр сведений, в котором можно будет указать дату очистки кэша, пользователя и флаг того что кэш очищен.

В процедуре ОбработчикОжиданияПроверкиДинамическогоИзмененияИБ(), если конфигурация изменена динамически, то добавлять запись с текущей датой по текущему пользователю. Флаг оставить как ложь.

В процедуре ПриЗавершенииРаботыСистемы() можно проверять не на то что конфигурация изменена динамически, а на наличие записи в регистре сведений без флага.

Если такая запись имеется, то чистим кэш и пишем в регистр флаг - истина.

Например, возникла следующая ситуация. Конфигурация была изменена динамически, но пользователь сам не закрыл 1С, ее вырубил админ на сервере или сам пользователь убил процесс. Таким образом, кэш не будет очищен ни при этом закрытии ни при следующем запуске - при следующем запуске конфигурация уже не будет изменена динамически. Но у нас в регистре же есть запись без флага. Система при следующем закрытии (да хоть после отпуска) все равно очистит кэш пользователя. Да к тому же программисту можно выборочно назначать счастливчиков.

Читайте также: