Обычный рабочий день, ничего не предвещало беды….
Позвонил один из пользователей и пожаловался на то, что в отчете по дебиторской задолженности дата претензии и дата направления претензии одинаковые, хотя в документе для этого есть два разных поля.
Покопавшись в отчете, выяснили, что оказывается, эти два поля берут свое значение из даты документа.Естественно, в копии. Далее, поправляем в рабочей базе, обновляем динамически. Платформа 8.3.27.1688.
И опа. Выскакивает ошибка SQL – превышено количество подключений, не успевая заскринить - все это валится, 1С исчезает с экрана. Думаем, ну ладно, бывает. Пытаемся снова войти в конфигуратор, и вот тут-то мы получаем:
Заходим в Администрирование серверов – видим интересную картинку: Соединения 0 – штук 10, от разных пользователей – похоже, это блокировка. Ну ладно, думаем, юзеры выйдут – все будет отлично, блокировка снимется и будем жить и радоваться. После того как дождались выхода всех пользователей – пытаемся снова зайти в 1С, ее заклинивает на этом сообщении.
Понятно, дело попахивает уже не очень хорошими вещами. Перезагружаем службы 1С.
Тут же организуем мини группу поддержки, пытаемся дотянуться до тех, до кого мы можем дотянуться. Сисадмины, знакомые, друзья в ИТ, связанные с 1С. Никто с подобным не сталкивался, начинается поток различных советов, первичное гугление не дает ничего интересного и полезного. Есть статья о том, как поправить Текущему соединению с информационной базой не назначен сеанс, но – эти советы не помогают. Очистить кэш сервера, очистить кэш пользователя. Крайний метод – убрать информационную базу из оснастки, не удаляя ее, и прописать заново.
Тут же пишем в техподдержку 1С, а вдруг. Не проходит и получаса, приходит сообщение от ТП –
Здравствуйте!
Резервную копию поднимать до повреждения базы.
Cпасибо за то, что делаете наш сервис лучше!
К этому моменту уже проделаны все основные танцы с бубном, которые не дали результатов.
Скопировали бэкапом SQL базу – развернули на другом сервере для экспериментов.
Наступает час Х. Все возможные статьи перечитаны, результаты экспериментов – неудовлетворительные. Тихо молимся своему богу. Звоним Гл.бухгалтеру – так и так, мол, мы все про... Нужно восстанавливать бэкап, т.к. вариантов нет. Готовимся отхватить люлей, отхватываем чуток. Обговариваем, как это будет выглядеть завтра и что всем сказать, и как все будут вручную восстанавливать день, бэкап есть ночной. Как будут восстанавливать обмен с ЭДО неизвестно, план покажет.
И тут приходит письмо от хорошего человека – я такую ситуацию словил на этой же платформе, делал вот это вот и это, не знаю, что помогло.
Начинаем изучать, первый пункт – это все, что мы могли проделать и проделали. Результата не дало.
Уточняем – говорит да, из этого скорее всего ничего не помогло, делаем дальше следующий пункт.
Итак, как оказалось, на нашем родном сайте Инфостарт есть уже статьи, и эти статьи уже размещены давно, т.е. проблема явно старая. Идем по всем советам, выбора нет, вариантов уже нет. На утро должно быть решение.
Первая //infostart.ru/1c/articles/116123/ - пробовали советы из этой статьи, копировали конфиг из ночной копии - в копию сломанную – начинает запускать в конфигуратор, затем при запуске ругается на то, что не находит таблицу Node…… Тестирование и исправление ИБ ругается дальше
Невосстановимая ошибка
Ошибка при выполнении запроса POST к ресурсу /e1cib/login:
по причине:
Ошибка при выполнении операции с информационной базой
Запись не найдена в менеджере имен базы данных.
Помогло старое решение, описанное здесь: //infostart.ru/1c/articles/138797/
А именно: delete from config where FileName = 'dbStruFinal'
Ребята, спасибо всем, кто помог. Благодарю также автора статьи, очень выручили ребят!
Спасибо, что делаете наш сервис лучше)
Вступайте в нашу телеграмм-группу Инфостарт
