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


А у вас как реализована борьба с кэшом? просто интересно..

(0) о чем речь? где постановка вопроса?

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

Почистил кэш - отвалилось торговое оборудование. Насколько это удобное удобство?

(3) Кэш надо с умом чистить. Не всё то, что в AppData\Local\1C - кэш. К сожалению, у кэша нет постоянного имени каталога.

(3) ССЗБ
(1) какое слово не понятно? там вопросиков несколько выбирай любой

(2) что значит откуда знает, ошибка с кэшем одна и ты же чистишь кэш и оно работает. Если в коде это другое и ошибка другая.

(0) Никак не боремся, уже лет 5 с 700+ пользователей онлайн в разных системах ниразу не возникало проблем. Динамическое обновление используем раз в 3 мес для хотфикса.

(4) ну про тех кто просто тупо всё убивает в \Local\1C я вообще молчу, они еще больше страдают))

(6) у юзера кэш сломался, ваши действия?

(4) Не все это знают. А в этих ваших интернетах, чистилки кэша именно такие. Так что для многих это неожиданно.

(8)
1. У пользователя удалить базу, добавить повторно.
2. Узнать кто динамически обновлял базу
3. Проверка ПК пользователи
4. Узнать были ли инциденты с зависанием сервера и обрыва сети

(10) 2. И что с ним сделать?

(10)Можно подумать что проблема с кэшэм возникает только из-за динамического обновления.

(12) пункты 2, 3, 4 - кому?

(0)Вот случилась проблема, когда надо почистить кеш. Как система должна понять, что его надо почистить? Что это не ты опечатался, а кэш не обновился. Или предлагаешь чистить после каждой ошибки? Где-то приблизительно раз в несколько лет на пользователя встречается задача очистки кеша. Ну как-то чистим. в маленьких компаниях, не возникает сложностей, чтобы необходимо было принимать меры. В организация где больше сотни пользователей, у всех пользователей вместе с 1С есть ярлык "очистка кеша". чтобы не бежать к пользователю. Кроме этих редких случаев чистить его не надо конечно же. чтобы не ждать гору времени, пока все метаданные скачаются по новой.

(13)Ну про 2 пункт я написал как раз в (12)

Что такое - "Проверка ПК пользователи", я не понял.

Ну и по вашему обрыв сети и зависание сервера(вероятно речь идёт о клиент-серверном варианте работы) создают проблему с кэшэм пользователей?

Если тормозит - добавьте кеширование, если глючит - уберите(с) не помню кто

(13) типа запретить динамическое наглухо? та ппц. решение оперативных проблем не слышали?

(10) 2. Узнать кто динамически обновлял базу...Главное не выйти на самого себя))

(14) "Как система должна понять, что его надо почистить?" а чего не понятно то? ошибка на кэш стабильна, очевидно если не играют локальные метаданные, чистим и грузим новые, зачем вылетать то?

(18) +1)))

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

(2) Конфа хранится в отдельных записях.

Кэш нужен, чтобы Клиентская часть 1С-а знала, что в конфе.

(21) Метаданные не хранятся в монолитном блобе. После разветывания конфы они хранятся в отдельных записях config

(24) Ну даже если так, всё равно, эти записи непригодны для непосредственного обращения по индексам, нельзя просто взять и дернуть с сервера модуль формы такого-то справочника.

(25) У них там в индексированном filename -е есть guid объекта. Поэтому - нет, можно выдернуть.
Но все равно это - время, которое, вы, кстати, видите, когда открываете конфигурацию (а особенно конфигуратор) первый раз.

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

Вот к примеру я внес изменения в код а метаданные не прокешировались. И при открытии обработки я получаю ошибку, что свойство объекта не обнаружено. Хотя оно есть абсолютно точно. Как же системе узнать, что надо обновить кеш?

(26) Так их чтобы выдернуть, надо парсить всё дерево конфигурации, с самого корня.

(28) Подобные доводы удивляют.. Война и мир - 3.5 мегабайта, а дерево конфигурации далеко не Война и мир. Самый несвежий комп способен "перечитывать" Войну и мир по 100 раз за секунду, а тут прям "всё дерево", "с самого корня".. Смешно!

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

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

(30) Да и в принципе - всё в компе "это текст", только алфавит в 256 символов. Вопрос именно в организации чтения. Осмысленного чтения. И тут со скорострельностью сегодняшних систем и объёмами доступной оперативной памяти... Даже интересно, куда именно девают такую производительность)

Да просто надо перестать всё завязывать исключительно на синтетическом уиде, и побольше использовать естественные ключи.. Но 1с почему-то очень уиды любит.

+(33) Например, в той же таблице config прямо напрашивается текстовое поле с развернутым полным путем до объекта метаданных. Чтобы можно было дернуть его сразу же, по мере необходимости, при обращении. А не ожидать, пока кэш с развернутым деревом конфигурации наполнится до нужной ветки.

(27) один разработчик в базе?
(32) на винду, куда же еще. растет мощность, растет потребность, это как спрос и предложение

+(34) Или, лучше, создать дополнительную таблицу для ускорения доступа, где бы хранились индексированные идентификаторы объектов метаданных и их уиды, с быстрым выбором уида по идентификатору, без разворачивания дерева. И обращение к метаданным платформой сделать через эту таблицу, не тратя времени на обход дерева конфигурации. Само собой, что взяли - кэшируем в памяти для быстрого повторного обращения, с соответствующей политикой вытеснения кэша. А персистентный кэш на диске - зло!

Полагаю, наступило время для голосовалки, т.к. данная проблема не у всех, не всегда,  иногда, никогда, не парит, бесит и т.п. Это просто одна из задачек, периодически возникающих при работе и техподдержке

(35)Не совсем понял вопроса, в одной базе может быть больше одного разработчика?

(27) у вас видимо мало опыта с этим или у вас просто уже настроено кем-то, поэтому и не видите. Ничего страшного, радуйтесь.
Эта "хрень" тянется со времен 8.1 и было что на ХР, что на 10-ке.

(37) я не смог сделать, нет возможности голосовалку как раньше.

(38) может, обычно так и бывает