День добрый. Есть Комплексная автоматизация 1.1.105.1. Платформа 8.2.19.130
PostgreeSQL.
Две базы, из одной в другую делается выгрузка данных.
С какого-то момента, скорее всего при обновлении, только вот каком х.з момент упущен, при попытке зайти в Мониторе обмена, в просмотр зарегистрированных к выгрузке в плане обмена стала выходить ошибка:
Ошибка SDBL: В схеме базы данных нет таблицы с именем q_000_t_001 (яндекс и гугл, ни чего путного не выдают, хотя фразу поисковую выдают сразу )
Программно так же нельзя ни очистить план обмена ни зарегистрировать. Выбивает с ошибкой и Программа вылетает.
В файловой версии - такого глюка нет. Все отлично заходится и чистится. Тестирование и исправление, а так же стандартная утилита для тестирования структуры базы данных(chdbfl.exe) - ошибок не находят.
Что можно сделать, как исправить, чтобы в sql версии так же можно было заходить в монитор обмена и редактировать список к выгрузке.
(23)т.е. ошибка снова возникает при следующем обмене...
А удалить полностью БД в постгри - пересоздать и уже в новую БД загрузить дт? или так и делал?)
Или рядом создать вторую базу и там проверить...
(16) Да оно видно по названию, что она временная, но что в ней хранится. У меня подозрение, что в плане обмена есть регистры, и когда форма зарегистрированных объектов получает записи регистра, образуется эта временная таблица и все падает. Я хотел предложить обработкой пробежаться по метаданным регистров и сделать срезы или получить остатки. Думаю на каком-то выйдет эта ошибка. Дальше колдовать с этим регистром. По идее я бы попробовал бы его изменить (добавить реквизит или измерение) и сделать реструктуризацию.
Почему регистр - потому что на сколько я помню, в узле плана обмена хранятся данные не во временной таблице, поэтому отпадает
(21) В них можкт храниться что угодно. В том числе временные метаданные при реструктуризации.
Но сами изменения конфы хранятся в таблице ConfigSave. Если Конфигуратор падает при запуске, надо дропнуть эту таблицу.
Я специально экспериментировал - в запросе помещал выборку во временную таблицу и её содержимое попадало в темповую таблицу скуля.
Когда в запросе написал ПОМЕСТИТЬ вт а потом УНИЧТОЖИТЬ вт, то квосты подчищалист и на сервре.
Просто однажды после разных падений и дисконнектов клиентов эта временная база забивалась и Конфигуратор падал при реорганизации.
Лечил перезапуском службы скуля.
(28) Я слегка термины перепутал и ввел в заблуждение. Не временная таблица, а виртуальная.
В вашем случае не понимаю, как временная таблица может влиять на конфигуратор, если только вы не о ConfigSave (она не временная), но если о ней, то не понимаю как вы ее
ПОМЕСТИТЬ вт а потом УНИЧТОЖИТЬ вт
.
В случае ТС, идет какой-то запрос к бд, создается некая временная таблица q_000_t_001, и она падает. Это моё предположение.
(30) Да это я изначально писал ТС, но ошибся сообщением.
(22) Не всегда. При выгрузке в dt большой базы (на моем примере база 180 ГиБ) и загрузке обратно падал конфигуратор с сообщением. что сервер SQL не ответил вовремя.
Хотя скуль работал без сбоев. Просто 1С решила, что "и так много поработали, хватит".
На маленьких базах сойдет.
(23)т.е. ошибка снова возникает при следующем обмене...
А удалить полностью БД в постгри - пересоздать и уже в новую БД загрузить дт? или так и делал?)
Или рядом создать вторую базу и там проверить...
(26)
в принципе только на этих выходных удалось получить в доступ сервер с 1С..
Помогло вот что..
1. Выгрузил базу в файловую и еще раз прогнал тестирование и исправление - особо ни чего не найдено
2. на всякий случай проверил внешней утилитой от 1С - ошибок нет
3. Удалил базу нафиг с сервера
4. заново создал в SQL базу и загрузил туда выгрузку
Взлетело...
При этом как советовали ранее, пробовали и КЭШ чистить и у пользователе я и на сервере, и Остановку служб делать, это не помогало...
То есть, причина проблемы - в точечной несовместимости 1С и имеющейся СУБД. Подтверждается это и тем, что в файловом варианте ошибка не воспроизводится.
Выводы? Лично я сделал следующий: поскольку работа платформы 1С оптимизируется под MS SQL (там такая проблема вроде бы тоже случается, но это - только со слов знатока из (19), то есть смысл подумать о переходе на эту СУБД. Затратно, поэтому лучше сначала потренироваться на кошках копии базы.
Или, как более дешевый вариант - ковырять отладчиком код, вызывающий ошибку и переписывать его, пытаясь угадать - какие нужно внести изменения для того, чтобы Postgree отработал корректно?
А потом, в случае успеха, повторять эти телодвижения после каждого обновления... и молиться, чтобы больше ничего подобного не вылезло в других местах.
(7) Такая ошибка наблюдалась при частых аварийных заверениях работы с базой.
Как на MS SQL 2014, так и на PostgreSQL.
На файловых такой проблемы нет, хотя там тоже некое подобие файлов баз скуль-сервера.
Лечение:
симптоматически: остановить сервер 1С, остановить сервер SQL. Очистить кеш клиентских баз 1С, очистить кеш на сервере 1С, очистить кеш у пользователя, от имени которого запускается "сервер 1С". Запустить службу SQL, запустить службу 1С.
административно: проверить все коннекты, настроить сеть, настроить сервер.
организационно: лупить по рукам пользователей и погромистов 1С, которые запускают запросы за неопределенный период или пишут кривые запросы.
Пишем грамотно:
"ни чего путного" -> "ничего путного"
"так же нельзя" - > "также нельзя" и в других местах "также" в данном контексте должно писаться слитно.
(20)пока нет.. остановка сервера и перезапуск служб не помогло...
К сожалению, телодвижения можно делать вечером, после рабочего дня.. Тут получается задержка