Добрый день!
Старенькая платформа 1С:Предприятие 8.2 (8.2.19.130)

Суть проблемы: есть сервер 1с, несколько баз УПП
Есть пара веб-сервисов, подключенных к этим базам

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

В одной базе - не работает (веб-сервисы идентичны)

В Журнале регистрации данные о том, что пользователь веб-сервиса прошел авторизацию и завершил сеанс есть.

Процедура выполняется, но выдает не тот результат, что я жду, это и причина, хочу понять что не так.

Что пробовали делать:
1) рестарт сервера 1с с запуском в режиме отладки сервера
2) прописывали в описании веб-сервиса дебаг
3) перезапускали апач (версия 2)

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

Проблемная база цепляется в отладке к клиентским и серверным сеансам.

Подскажите пожалуйста, из-за чего еще может не работать отладка?

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

(1) - это тебе моральная поддержка, ты не одна такая))

(1) я подожду два года:)))))))))))))))) пользователь будет счастлив:)))

(2) спасибо:))

(0) Сделай копию базы, попробуй там отладить

(4) это сработает, т.к. тестовый сервер у нас другой, там отладка работает
Но это не решит проблему

(1) вот это наталкивает на мысль про серверный кэш

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

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

(7) ну и ты терпила ))

(8) есть более изощренные методы отладить веб-сервис))

(5) очень проблематично, база живая 24/7

(7) жаль, но я все же попробую вечером это
как вариант

(10) если под "серверным кэшем" понимается что-то помимо СУБД, можно попробовать

Но если ты можешь позвонить себе рискнуть почистить кэш на сервере с базой 24/7, почему не можешь позволить себе сделать копию и переопубликовать? Или база большая сильно = долго по времени?

(11) у меня окно технологическое есть 10 минут - успею с кэшем
с копией более долгий процесс, база большая ~400 гб

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

Выход из ситуации конечно нашла

Сделала ЗаписьЖурналаРегистрации

Вывела в журнал регистрации текст выполняемого запроса

Тоесть я вижу, он заходит, что-то делает

Но тем не менее, в отладку не цепляется

(15) проблему с результатом запроса я решила

А вот с отладкой - нет. Актуально :(

Ну как, пробовала чистить кэш?

" в файле default.vrd
<debug enable="true" url="tcp://localhost"/>
перед закрывающим тегом </point> "

(17)
не работает, о чем я в (0) писала
2) прописывали в описании веб-сервиса дебаг


(16) в это окно нет, там еще были плановые работы. Попробую в следующее

(0) Может поможет:
У меня была проблема с отладкой фоновых заданий из-за того, что строка подключения для запуска конфигуратора не совпадала со строкой подключения фонового задания. Здесь подробно об этом написано:
http://professia1c.ru/reglamentnyie-zadaniya/otladka-fonovyih-zadaniy/

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

(19) спасибо, проверю

(20) так об этом и тема - как?:)

Тема не об этом

А переопубликовать Web сервис через конфигуратор,чтобы он знал,что сервис существует?

(22) вам виднее, спору нет


(23) у нас линуксовый, там не через конфигуратор публикация