Ошибка SDBL: Таблица или поле не содержится в разделе FROM при загрузке в подчиненный узлел РИБ
Исходные данные на постгресе9 живет типовая УПП 1.3. Имеется РИБ состоящий из 3х точек (центральный узел+2 подчиненых узла).
При очередном обновлении на свежий релиз (157-158) получил указанную ошибку
Ошибка SDBL: Таблица или поле _Fld34480 не содержится в разделе FROM
При этом второй подчиненный узел обновился без ошибок и успешно работает.
Поиск по структуре метаданных в центральном узле результата не дал - такое поле отсутствует, этого поля нет и в обоих подчиненных узлах).
Включил техжурнал 1с: в нем удалось отловить событие по сосзданию таблицы _InfoRG33542NG с указанным полем _Fld34480. (результат отработки sql успешно создана, а по факту в постгресе такой таблицы не вижу.)
Совершенно не пойму куда копать. Как исправить?
Руками добавить таблицу в постгрес, но может надо добавлять не одну или ещё чтонибудь - а где посмотреть какие изменения вносятся в структуру при РИБ (если тупо стравнить две конфы - то там нет упоминания об этой таблице - ведь и ЦБ и ПодчинУзел_1 живут без этой таблицы, но при этом ПодчинУзел_2 у себя зачем-то хочет создать её)
При очередном обновлении на свежий релиз (157-158) получил указанную ошибку
Ошибка SDBL: Таблица или поле _Fld34480 не содержится в разделе FROM
При этом второй подчиненный узел обновился без ошибок и успешно работает.
Поиск по структуре метаданных в центральном узле результата не дал - такое поле отсутствует, этого поля нет и в обоих подчиненных узлах).
Включил техжурнал 1с: в нем удалось отловить событие по сосзданию таблицы _InfoRG33542NG с указанным полем _Fld34480. (результат отработки sql успешно создана, а по факту в постгресе такой таблицы не вижу.)
Совершенно не пойму куда копать. Как исправить?
Руками добавить таблицу в постгрес, но может надо добавлять не одну или ещё чтонибудь - а где посмотреть какие изменения вносятся в структуру при РИБ (если тупо стравнить две конфы - то там нет упоминания об этой таблице - ведь и ЦБ и ПодчинУзел_1 живут без этой таблицы, но при этом ПодчинУзел_2 у себя зачем-то хочет создать её)
Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Забыл уточнить: эти базы живут на двух серверах 1с (8.3.11.3034). Перекладывание проблемной базы с одного на другой результата не меняет, т.е. чистить кэши и грешить на платформу нельзя, т.к. ЦБ и ПодчинУзел_1 - живут на любом из этих серверов.
с помощью ddl триггера или тех журнала воспроизведите таблицу _InfoRG33542 из _InfoRG33542NG
в постгре скл ддл триггеры появились в версии 9.5. создайте в вм постгре 9.5 . разверните копию базы настройте триггер . полученную структуру таблиц перенесите в постгре 9
в постгре скл ддл триггеры появились в версии 9.5. создайте в вм постгре 9.5 . разверните копию базы настройте триггер . полученную структуру таблиц перенесите в постгре 9
структуру таблицы _InfoRg33542NG я отловил через техжурнал и создал её в постргресе (результата загрузки РИБ жду), а как найти откуда 1с знает о необходимости её (таблицы) создания, если в структуре метаданных исходной БД эта таблица отсутствует?
В тех журнале видно как создавалась таблица с проблемным полем (проблемное поле не первое и не последнее, но ругается пока на него) вместе с тем полей создается куча, ругается только на него (_Fld34480), таблица вроде как "не случайная", а вполне осмысленная, т.е. вродебы рукотворная - но почему её нет в структуре метаданных ЦБ и ПодчинУзел_1. И в техжурнале написано - создано успешно (Result=PGRES_COMMAND_OK)
В тех журнале видно как создавалась таблица с проблемным полем (проблемное поле не первое и не последнее, но ругается пока на него) вместе с тем полей создается куча, ругается только на него (_Fld34480), таблица вроде как "не случайная", а вполне осмысленная, т.е. вродебы рукотворная - но почему её нет в структуре метаданных ЦБ и ПодчинУзел_1. И в техжурнале написано - создано успешно (Result=PGRES_COMMAND_OK)
06:11.205000-7998,
DBPOSTGRS,3,process=rphost,p:processName=upp02,OSThread=31915,t:clientID=611,t:applicationName=Designer,t:computerName=Ast-36,
t:connectID=450,SessionID=10,Usr=ТишковскийДВ_02,Trans=0,dbpid=18455,
Sql='dr op table if exists _InfoRg33542NG cascade;
cre ate table _InfoRg33542NG ( _Fld33547_TYPE bytea not null,
_Fld33547_RTRef bytea not null,
_Fld33547_RRRef bytea not null,
_Fld33549RRef bytea not null,
_Fld33550 timestamp not null,
_Fld34480 timestamp not null,
_Fld34481 mvarchar(50) not null,
_Fld34482RRef bytea not null,
_Fld34483RRef bytea not null,
_Fld33551RRef bytea not null,
_Fld33552 boolean not null,
_Fld33553 boolean not null,
_Fld33554 boolean not null,
_Fld33555 boolean not null,
_Fld33556 boolean not null,
_Fld33557 boolean not null,
_Fld33558 boolean not null,
_Fld33559 boolean not null,
_Fld33560 boolean not null,
_Fld33561 boolean not null,
_Fld33562 mvarchar(250) not null,
_Fld33563 mvarchar(250) not null,
_Fld33564 numeric(15, 2) not null,
_Fld33565_TYPE bytea not null,
_Fld33565_RTRef bytea not null,
_Fld33565_RRRef bytea not null,
_Fld33566_TYPE bytea not null,
_Fld33566_RTRef bytea not null,
_Fld33566_RRRef bytea not null,
_Fld33567 mvarchar(250) not null,
_Fld33568RRef bytea not null,
_SimpleKey bytea not null ) without oids '
,RowsAffected=0,Result=PGRES_COMMAND_OK
06:11.208000-2999,
DBPOSTGRS,3,process=rphost,p:processName=upp02,OSThread=31915,t:clientID=611,t:applicationName=Designer,t:computerName=Ast-36,
t:connectID=450,SessionID=10,Usr=ТишковскийДВ_02,Trans=0,dbpid=18455,
Sql=' ALT ER TABLE _InfoRg33542NG ALTER COLUMN _Fld33547_TYPE SET STORAGE PLAIN;
ALT ER TABLE _InfoRg33542NG ALTER COLUMN _Fld33547_RTRef SET STORAGE PLAIN;
ALT ER TABLE _InfoRg33542NG ALTER COLUMN _Fld33547_RRRef SET STORAGE PLAIN;
ALT ER TABLE _InfoRg33542NG ALTER COLUMN _Fld33549RRef SET STORAGE PLAIN;
ALT ER TABLE _InfoRg33542NG ALTER COLUMN _Fld34482RRef SET STORAGE PLAIN;
ALT ER TABLE _InfoRg33542NG ALTER COLUMN _Fld34483RRef SET STORAGE PLAIN;
ALT ER TABLE _InfoRg33542NG ALTER COLUMN _Fld33551RRef SET STORAGE PLAIN;
ALT ER TABLE _InfoRg33542NG ALTER COLUMN _Fld33565_TYPE SET STORAGE PLAIN;
ALT ER TABLE _InfoRg33542NG ALTER COLUMN _Fld33565_RTRef SET STORAGE PLAIN;
ALT ER TABLE _InfoRg33542NG ALTER COLUMN _Fld33565_RRRef SET STORAGE PLAIN;
ALT ER TABLE _InfoRg33542NG ALTER COLUMN _Fld33566_TYPE SET STORAGE PLAIN;
ALT ER TABLE _InfoRg33542NG ALTER COLUMN _Fld33566_RTRef SET STORAGE PLAIN;
ALT ER TABLE _InfoRg33542NG ALTER COLUMN _Fld33566_RRRef SET STORAGE PLAIN;
ALT ER TABLE _InfoRg33542NG ALTER COLUMN _Fld33568RRef SET STORAGE PLAIN;
ALT ER TABLE _InfoRg33542NG ALTER COLUMN _SimpleKey SET STORAGE PLAIN;
'
,RowsAffected=0,Result=PGRES_COMMAND_OK
06:11.213000-3999,
DBPOSTGRS,3,process=rphost,p:processName=upp02,OSThread=31915,t:clientID=611,t:applicationName=Designer,t:computerName=Ast-36,
t:connectID=450,SessionID=10,Usr=ТишковскийДВ_02,Trans=0,dbpid=18455,
Sql='create unique index _inforg33542_bydims_rrng on _inforg33542ng(_Fld33547_TYPE,
_Fld33547_RTRef,
_Fld33547_RRRef,
_Fld33549RRef);
alt er table _inforg33542ng cluster on _inforg33542_bydims_rrng; '
,RowsAffected=0,Result=PGRES_COMMAND_OK
Показать
После создания таблицы на постгресе при загрузке РИБ - эта ошибка ушла, но теперь ругается на другое поле Fld34490
Понятно, что можно создать и его вместе с его таблицей, но этих таблиц в структуре 1с НЕТ!!! - откуда 1с их берет? Сколько их ещё? В второй ПодчинУзел_1 их тоже нет.
Понятно, что можно создать и его вместе с его таблицей, но этих таблиц в структуре 1с НЕТ!!! - откуда 1с их берет? Сколько их ещё? В второй ПодчинУзел_1 их тоже нет.
Как уже писал ранее: отловил техжурналом проблемный запрос
Код почемуто спотыкается на создании реквизита _Fld34480. Решил ему помочь - па постгресе создал нужную ему таблицу.
На "втором круге" загрузки РИБ он захотел создать и споткнулся на _Fld34490 - я создал и её. На третьем повторилась закономерность теперь просит _Fld34500. Попробую сейчас на 2хода создать _Fld34510 и _Fld34520 , но предполагаю что попал в бесконечный цикл.
Как прервать не пойму. Сказать конфе что она идентична ЦБ, руками перелить записи dbnames таблицы params, а после симптоматически докидать недостающие таблицы? Еще способы есть?
Но ведь цепляется только за это поле, к другим ни до ни после вопросов нет - странно.
Примечательно, скрипт создает таблицу infoRg33542NG - предположительно регистр сведений и ng указывает на то что это новая структура и после переименовывает её в infoRg33542. Т.о. после обработки мною созданной таблицы 1с движек с ней работал, но зачем-то в неё хочет запихнуть новую структуру и так по кругу...
cre ate table _InfoRg33542NG (_Fld33547_TYPE bytea not null,
_Fld33547_RTRef bytea not null,
_Fld33547_RRRef bytea not null,
_Fld33549RRef bytea not null,
_Fld33550 timestamp not null,
_Fld34480 timestamp not null,
_Fld34481 mvarchar(50) not null,
_Fld34482RRef bytea not null,
_Fld34483RRef bytea not null,
_Fld33551RRef bytea not null,
_Fld33552 boolean not null,
_Fld33553 boolean not null, ПоказатьКод почемуто спотыкается на создании реквизита _Fld34480. Решил ему помочь - па постгресе создал нужную ему таблицу.
На "втором круге" загрузки РИБ он захотел создать и споткнулся на _Fld34490 - я создал и её. На третьем повторилась закономерность теперь просит _Fld34500. Попробую сейчас на 2хода создать _Fld34510 и _Fld34520 , но предполагаю что попал в бесконечный цикл.
Как прервать не пойму. Сказать конфе что она идентична ЦБ, руками перелить записи dbnames таблицы params, а после симптоматически докидать недостающие таблицы? Еще способы есть?
Но ведь цепляется только за это поле, к другим ни до ни после вопросов нет - странно.
Примечательно, скрипт создает таблицу infoRg33542NG - предположительно регистр сведений и ng указывает на то что это новая структура и после переименовывает её в infoRg33542. Т.о. после обработки мною созданной таблицы 1с движек с ней работал, но зачем-то в неё хочет запихнуть новую структуру и так по кругу...
Мне непонятна причина какого фига 1ска вообще хочет эту таблицу создавать. В цб ее нет ни на стороне метаданных ни на стороне постргеса. Во второй переферийке тоже нет. Т.е. те 2 базы живут нормально. По идее достаточно в этой иб перетереть ячейку dbnames, но после могу получить типа сруктура не соотв конфе... а значит хотябы надо ее (ячейку) както хотябы глазами сличить. Ячейка бинари. Чем прочитать пока не знаю.
(23) 1) в postgsql9 нет типа бинари. 2)запись dbnames была бы легко сравнима,тк - текст. но она сжата по алгоритму deflate. что прямое сравнение делает бессмысленным.
3) в таблицах бд не ячеек. есть записи и поля.
и 1 ) и 2) описаны широко в интернет . 3) - базовые знания. для общения не владеете базовой терминологией.
а по существу: у вас в бд произошло рассогласование сопоставления метаданных и имен таблиц (полей) бд. книгу проф.разработка Вы не читали. и понимания работы бд и 1с8 у Вас нет.
обратитесь за платной консультацией в компании франчайзи 1с , имеющих соответствующий опыт. тк многие Ваши домыслы не правильны.
3) в таблицах бд не ячеек. есть записи и поля.
и 1 ) и 2) описаны широко в интернет . 3) - базовые знания. для общения не владеете базовой терминологией.
а по существу: у вас в бд произошло рассогласование сопоставления метаданных и имен таблиц (полей) бд. книгу проф.разработка Вы не читали. и понимания работы бд и 1с8 у Вас нет.
обратитесь за платной консультацией в компании франчайзи 1с , имеющих соответствующий опыт. тк многие Ваши домыслы не правильны.
Да, нашел я описания, спасибо (вчера штудировал):
Params (служебные параметры информационной базы) DBnames
Файл сжат по алгоритму deflate. Начинается с указания количества содержащихся в нём элементов. Содержит список структур DBNameEntry, которые описывают объекты хранения данных в СУБД: основные и вспомогательные таблицы, таблицы настроек, поля этих таблиц и т.п.
{28439047-46ca-4fba-9e2b-a3ac9f95a2c3,"Fld",18},
{4e75ac96-7c81-4c57-af12-a52eebdb576a,"Fld",19},
Вы правы, потребности в этом не было, следовательно и знаний не было.
Поправьте меня если не прав:
Могу смоделировать проблему на конфе пустышке если закину через backup/restore в нее DBSchema, Params (полностью в т.ч. DBnames), Config, v8users(опционально) - после зайду в режим предприятия - загружу из РИБ (ругнется на номер сообщение - исправить) очередной пакет обмена в т.ч. ConfigSave (или тоже можно через backup/restore из ЦБ) и при попытке загрузки конфы должен получить мою туже ошибку. Далее перезаливаю Params (полностью в т.ч. DBnames) из живой другой рабочей переферийной базы - моя ошибка купирована. В ЦБ релиз158, в ПерефБазе1 тоже уже релиз 158, в проблемной базе застопорился на релизе 157 - по идее отличия в структуре метаданных возможны и тогда ругнется на отсутствующие таблицы на постгресе - их тоже можно будет досоздать.
Params (служебные параметры информационной базы) DBnames
Файл сжат по алгоритму deflate. Начинается с указания количества содержащихся в нём элементов. Содержит список структур DBNameEntry, которые описывают объекты хранения данных в СУБД: основные и вспомогательные таблицы, таблицы настроек, поля этих таблиц и т.п.
{28439047-46ca-4fba-9e2b-a3ac9f95a2c3,"Fld",18},
{4e75ac96-7c81-4c57-af12-a52eebdb576a,"Fld",19},
Вы правы, потребности в этом не было, следовательно и знаний не было.
Поправьте меня если не прав:
Могу смоделировать проблему на конфе пустышке если закину через backup/restore в нее DBSchema, Params (полностью в т.ч. DBnames), Config, v8users(опционально) - после зайду в режим предприятия - загружу из РИБ (ругнется на номер сообщение - исправить) очередной пакет обмена в т.ч. ConfigSave (или тоже можно через backup/restore из ЦБ) и при попытке загрузки конфы должен получить мою туже ошибку. Далее перезаливаю Params (полностью в т.ч. DBnames) из живой другой рабочей переферийной базы - моя ошибка купирована. В ЦБ релиз158, в ПерефБазе1 тоже уже релиз 158, в проблемной базе застопорился на релизе 157 - по идее отличия в структуре метаданных возможны и тогда ругнется на отсутствующие таблицы на постгресе - их тоже можно будет досоздать.
Прикрепленные файлы:
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот