Сломал голову.
Обновил УНФ с 1.5 до версии 1.6

Имеется: типовая демо УНФ 1.6
Обновленная до УНФ 1.6 копия рабочей

Обе базы на платформе 8.3.6.2449
у обоих одинаковые настройки режима совместимости(типовые УНФ 1.6 - Не использовать)

но в типовой УНФ 1.6 - не выдает ошибку на стрНайти, в обновленной до 1.6 - выдает.

какое-то еще свойство ИБ или конфигурации нужно установить?

(0)>>у обоих одинаковые настройки режима совместимости(типовые УНФ 1.6 - Не использовать)

Зуб даешь? Если да, то попробуй (как вариант), почистить кэш.

Поищи эту функцию, где она объявлена и разбирайся с областью видимости

перезапустил конфигуратор, проблема исчезла

странно

КЭШ

Когда они уже жтот кеш починят???

(6) зачем?

(6) А про что еще ветки на Мисте создавать?

(7) Потому что продукт должен работать нормально без вмешательства в инфраструктуру его данных извне. такое вмешательство допустимо в редких случаях специалистом ДЛЯ ПОЧИНКИ/ДИАГНОСТИРВОАНИЯ ПРОБЛЕМЫ. на мой неквалифицированный взгляд количестов советов "почистить кеш" и сообщений "перезапустил комп - просблема счезда/почистил кеш проблема исчезла" - превышает допустимые пределы. То есть "почитсить кеш - это уже превратилось в НОРМУ. имхо - это бяка. Что-то там не так с управлением кешем.

(9) НЕНАВИСТЬ!!1 =)

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

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

Встретилось: СтрНайти(ТекстДанныхВыгрузки, "###***###")  
"###***###" - вроде как шаблон, какой, что найти нужно?

(9) Гарантировать актуальность кэша может только проверка контрольных сумм кэшированных (мета)данных. Реализовать в платформе такое несложно, но это будет расходовать процессорное время. Хотя, с учетом того, что платформа уже не запускается на старом железе, этот расход процессорного времени можно считать пренебрежимо малым. Непонятно, почему так не сделают..

(10) Вот поэтому фраза "восьмерка еще сырая" до сих пор актуальна)

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

(13) "Прожарка с кровью" уже актуальней =)

(11) Найти шаблон "###***###", разумеется. Тебе угрожают оружием, чтобы ты не открывал СП?

(9) Ты уже забыл: "Комп перегружали?", "А в дисководе дискетка не стоит?" :))

(6) Это вопрос к гейтсу

(9) Давно уже все ругаются, но повлиять на майкрософт не просто.

(13) Десятка уже вышла, там тоже самое.

(18)А Гейтс тут каким боком?

+(21)(19)И майкрософт тут не при чем. (20)И винда тут не при чем. Проблема чисто в 1с.

(22) Ну вот мы и определили виновного, коллеги! Каким же будет наш справедливый приговор?

(23) Повинен смерти же возвёдший хулу на бога нашего!

(24) Так он же про слуг его, может не надо сразу сжигать молниями, ну он будет каяться и приносить дары в процентах от продаж :)

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

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

(9) +100
на мой взгляд - логично при обновлении конфы очищать кеш

Логично - это когда платформа сама обновляет кэши в случае необходимости. Следит же она за кэшированием данных информационной базы - почему же тут такие досадные проколы во время обновления конфигурации? Это риторический вопрос.

(27) Гениально!
https://hh.ru/vacancy/12526356
Давай, ты сможешь, я в тебя верю! =)

(30)  так там зп не написана

(28) И на отключенных клиентах тоже, само собой разумеется! Кстати, кэш 1С бывает трёх видов. Ты про какой сейчас?

(31) Думаешь, его не оценят? Жаль, это ведь реальный шанс изменить мир.

(25) Вот учитесь - человек, практически, бизнес план на системе франчайзи предлагает =) Которые приносят процент и попутно занимаются покаянием. Их наоборот, поощрять надо!

(27) Давай продолжим =)

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

Первый сеанс задумчиво смотрит на список своих закэшированных объектов...

(35) Ну не повезло клиенту, его метаданные будут незакэшированы. Бывает. Не катастрофа, в отличие от непонятных глюков с неконсистентным кэшем.