Второй уже раз ловлю такой глюк. Первый раз было на клиентской машине (толстый клиент), сейчас вот - на сервере (регламентная задача - обмен данными XML). Выпадает сообщение об ошибке, в строке, которой не существует (я до этого удалил этот кусок кода и написал другой). Конфигурацию ИБ я точно обновил - проверял. К томуже если запускать эту регламентную задачу вручную на клиенте - все проходит без ошибок.
В первый раз глюк вылечил удалением каталогов 1с8 в Documents And Setings. Сейчас наверное тоже так буду делать, хотя на сервере страшновато - не увалить бы лишнего. Да, рестарт службы делал - не помогло.
Релиз сейчас 8.2.15.289, Комплексная Автоматизация 1.1.20.2. Клиент был на XP, сервер на 2008R2, SQL2008.

не обновляйтесь динамически и не будет проблем.

"Релиз сейчас 8.2.15.289"

срочно меняй на 317-й

Да, динамически как раз обновлял. Это ведь удобно :)
Релиз планирую обновить.

ЗЫ. А каков механизм возникновения этой проблемы, кто знает?

(3) Конечно удобно. Обновил - а потом с большой вероятностью пожинаешь проблемы типа (0) :-)
Механизм - в кешировании.

не зря его прозвали "демоническим обновлением"

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

у тебя очень просто все это проявилось. У меня один раз было - ошибок нет, все гут, но вдруг один из клиентов, заметил что отчет ОСВ по счету в БП 2.0 стал показывать по счету ГТД по некоторым позициям задвоенные данные.

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

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

С тех пор, сначала при разборе проблем - всегда взял за правило. Не лезь у конфигуратор не почистивши кэш :)

(6) "Чудны дела твои, Господи". А в каком файле/каталоге этот кэш лежит?

(7) Для чистки кэша есть ключ командной строки запуска.

/ClearCache - это ключ командной строки, который ЯКОБЫ очищает кэш. ЯКОБЫ тут ключевое. Может очистить, а может и нет :)

Физически локальный пользовательский кэш валяется в
C:\Documents and Settings\<Пользователь здесь>\Application Data\1C\1Cv82 - там будут каталоги, аля 30078244-7612-4df0-af63-248013d19bc3 и т.д. Находишь такой каталог для своей базы. Это и есть локальный кэш. Но если ты знаешь, что именно на этой машине нужно чистить кэш, то проще всего либо написать батник и его запускать, либо просто базу грохнуть из списка баз и переподцепить заново.

Кстати, не только демоническое обновление "портит" и не обновляет кэш. Как бы ни казалось странным, но даже простая работа пользователя тоже влияет на это. Напр, на всех релизах БП 2.0 наблюдается иногда такая картинка - когда пользователь начинает двигать форму документов, то иногда бывает что командные панели до неузнаваемости преобразуются в какую-то хню, которая мало похожа на командную панель :) очистка кэша это лечит.

"/ClearCache"? Вроде он только для клиентов, а мне на сервере надо почистится

(10) так ты на сервере клиент запускаешь, нет?

C:\Users\Пользователь\AppData
там в трех папках, будут папки 1С, их нужно руками почистить.
Только в одной есть кататог 1Cstart,(как-то так), её лучше оставить, там список баз хранится, чтоб потом не прописывать повторно

(11) на сервере регламентное задание запускается с граблями
(12) пасиб, буду чиститься с божей помощью (и вашей тоже ;) )

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

только не надо удалять списки баз и шаблоны конфигураций. данные полнотекстового поиска - опционально