Всем привет!

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

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

Подскажите плиз куда копать?

Почисти таблицу Config от лишних записей

прошу прощения опечатался, про директивы. Хотел написать не каких кроме НаСервере и НаКлиенете

(0) У тебя точка останова не останавливается или как ты определяешь, что код не работает? Когда отладка на сервере отключена, то ты просто не увидишь (через отладчик) выполнение серверных процедур

что за код?

В табло переменных что написано?

Результат работы кода отображается на форме. Отладка подключена - результат есть, Отладка отключена - результата нет.

(1) Как это сделать безопасно? Нельзя же просто взять и очистить таблицу? Как определить какие записи лишние?

(7) обновить конфигурацию монопольно

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

(9) Это уже все опробовано и код рабочий. В режиме отладки на сервере же он работает...

(8)  и (1)  предложения звучат разумно. Но вот прям сейчас обновить монопольно нет возможности, вечером можно будет попробовать. А вот как безопасно почистить конфиги пока не разобрался. В SQL Есть 2 таблицы конфиг. Насколько я понял одна Это конфигурация БД, вторая основная Конфигурация. Вероятно где то они между собой конфликтуют.... Кто может подсказать где можно почитать на тему как их ручками синхронизировать?

Точно дело в отладке а не в режиме запуска (Тонкий/Толстый)

(12)+ ?

Точно. Более того Захожу в конфигуратор, оттуда запускаю отладку, проверяю, все работает. Не закрывая сеанса, отсоединяю отладку проверяю снова - не работает.

Вообще Режим запуска это первое на что подумал, после кэша.

Гейзенбаг (англ. heisenbug) — жаргонный термин, используемый в программировании для описания программной ошибки, которая исчезает или меняет свои свойства при попытке её обнаружения.

Ну я бы проверил на другом компе/сервере

(14) Покажи код, который не работает

(15) Прикольно. Новый для меня термин, буду знать :)

(16) На другом компе поведение такое же.  

(17) Не знаю как это поможет но всё же:

Строка где написано РасчитатьИЗаполнитьПремиальныеДляСборщиков не работает без отладки и работает с отладкой

&НаКлиенте
Процедура РасчетСдельныхПремий(Команда)
    //Вызовим типовую команду заполнения документа
    Заполнить(Команда);
    
    //Расчет ЗП
    РасчитатьИЗаполнитьПремиальныеДляСборщиков();
    
    //Типовая команда после ввода данных в строках
    РасчетЗарплатыКлиент.СтрокаРасчетаПриОкончанииРедактированияСотрудников(ЭтаФорма, ОписаниеТаблицыНачислений(ЭтаФорма));
КонецПроцедуры

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

то есть в (0) было динамическое обновление?

(20) Очень похоже на это

попробуй сообщить в разных местах

(18) >На другом компе поведение такое же.
Очень странно

Используй (22) внутри РасчитатьИЗаполнитьПремиальныеДляСборщиков()

(23)+ Еще лучше пиши в файл лога вместо Сообщить

(24)+ В 1С есть ЖР, но мне неудобно его как лог

(22)(23) был опыт? у меня в 8.3.10 похожий барабашка

И так отчитываюсь о проделанной работе.

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

В монопольном режиме все обновил. И о чудо проверяю без отладки, все работает.

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

Как такое вообще может быть? На сервере я документ на котором проверю даже не закрывал. Просто еще раз нажал для проверки в уже открытом документе и у меня на ходу то что работало перестало работать.

(27) это все фиксики виноваты, пока вы бегали к буху, они ваше обновление отменили. Скорее всего в сговоре с бухгалтером(
А если серьезно, у меня что-то подобное было при динамическом обновлении и PostgreSQL в далеком 2014г. На мелкомягком скуле такой проблемы не замечал. Попробуйте на бекапе поиграться. Выгрузить/загрузить в отдельную базу копию рабочей. В этой копии сделать эти же изменения и проверить под бухом будет ли в копии работать.
Для очистки кэша я обычно удаляю полностью все папки с гуидами из папок Local и Roaming, чтобы наверняка.

(28) на крайняк попробовать еще версию платформы сменить

(29) + и бухгалтера

(18) По-русски говорят "плавающая ошибка" или "глюк".

(30) И место работы )))

(27) Это потому что ты так и не почистил таблицу Config и/или ConfigSave и/или серверный кэш пользователя ОС службы агента и/или не рестартанул после этого кластер (с очисткой кэша из предыдущего условия).
ConfigSave полностью чистишь. В Config - только записи с FileName = commit / dbStruFinal / %dyn%.