Добрый день! Возникает ошибка при выгрузке БД в конфигураторе https://ibb.co/M5kpxKz. База клиент-серверная, платформа 8.3.12.1790, СУБД PostgreSQL Pro 10.6.1
Бэкапы создаются средствами СУБД по расписанию.
Пробовал в "песочнице" развернуть бэкап в более новые версии СУБД и на более новых версиях платформы, ничего не меняется. Кто-нибудь с подобным сталкивался? Что можно сделать?

В ЖР единственное что написано: "Ошибка выгрузки файл .dt"

Всегда вызывало умиление вот такая публикация ошибки.
Прям как Стивен Кинг - все вроде раскрыто, но самая интрига - за завесой тайны.

(2) Я бы хотел узнать, как еще можно выяснить причину этой ошибки?

(3) Верная же ссылка в яндексе
http://dr2c.blogspot.com/2018/11/posgresql-1-mssql.html

(4) Так и знал, что мне здесь выложат эту ссылку. Нет никакой таблиц configcas и  configcassave. Это не актуально.

В MS SQL я бы профайлером собрал трассу по посмотрел таблицу на которой спотыкается. Что скажут адепты postgree ?

(6) в постгре тоже есть профайлер, конечно не такой навороченный, но все навороты то и не нужны

(7) Как можно им воспользоваться? Мне бы хоть понять, о какой таблице идет речь. А то ничего не написано.

Расширения?

напиши скрипт и в копии проселекти все таблицы полным сканированием,сразу станет ясно.

(10) Можно подробнее?)) Какой скрипт?

(9) Одно расширение было, я его удалял, после этого ничего не меняется.

(12) То есть запускал на всякий тестирование (реструктуризацию), все равно ошибка в конце.

(0) в журнале pgsql посмотри FROM откуда конкретно она пытается сделать SELECT (при необходимости log_statement = 'all')

и посмотри, какие там есть колонки

возможно, база перекочевала из PG-9 в PG-10 и с тех пор с ней никаких операций выгрузки-загрузки не производили:
8.3.13.1644 и PosgreSQL: ошибка "variable not found in subplan target lists"

(14) Был раньше MSSQL. Затем базу загрузили на Linux-сервер, где уже была PostgreSQL. Есть у меня информация, что эту базу восстанавливали из бэкапа средствами СУБД. Но с чего именно все началось я не знаю((

(15) PostgreSQL с самого начала была 10.6.1

(15) (16) хорошо, значит в mssql была такого же формата база, без колонки filename

либо ищи способ загрузить ее взад в mssql, а оттуда - в dt

либо ставь рядом pg-9.6, загружай туда, в dt и обратно


либо хотя бы скажи название таблицы, в которую добавили колонку FileName, т.к. я ее название забыл сразу же после того, как свою проблему решил

(17) В том-то и дело, я не могу найти название этой таблицы, даже не знаю как. Журнал psql как можно посмотреть?

(17) Простите, я похоже неверно выразился, а меня неправильно поняли) Базу с MSSQL в PostgreSQL переносили обычной выгрузкой/загрузкой dt

Но однажды, уже на Linux-сервере пришлось восстановить базу из бэкапа.

В postgresql.conf: log_statement = 'all'
перезапуск postgres

попытка выгрузки, чтобы напороться на ошибку

в логах (каталог log либо pg_log) смотри последний файл

grep -i filename xxx.log

как найдешь - log_statement обратно в none и перезапуск, иначе весь диск засрет

2019-04-27 14:31:42.233 MSK [1272] ERROR:  column "filename" does not exist at character 53
2019-04-27 14:31:42.233 MSK [1272] STATEMENT:  DECLARE mycursor BINARY NO SCROLL CURSOR FOR SELECT FileName, Creation, Modified, Attributes, DataSize, BinaryData, PartNo FROM DepotFiles ORDER BY FileName, PartNo

Такой вот лог. Получил список всех таблиц, среди них нет "DepotFiles". Нашел похожую топик, но тема так и не раскрыта( За что отвечает таблица depotfiles ?
Что можно попробовать сделать в такой ситуации?

Создал пустую ИБ, в консоли администрирования сервера приложений.
В списке таблиц PostgreSQL таблица depotfiles присутствует, пустая. Структура у нее такая же как и у других таблиц Хранилища поименованных двоичных данных (файлов) (config, configsave и т.д.). В *.dt выгружается без ошибок.
Удалил руками таблицу - drop table depotfiles;
Выгружается в *.dt и загружается назад тоже нормально, может быть из-за того, что таблица была пустой.
Потом сделал реструктуризацию таблиц ИБ(ТиИ), таблица depotfiles появилась в списке.
(22) Попробуйте реструктуризацию, хотя если в вашей базе эта таблица была непустой, может ничего и не даст.

(23) Реструктуризация заканчивается той же ошибкой, описанной в (0)

Создайте пустую таблицу depotfiles я думаю, это решит вашу проблему

(22) а есть ли у пользователя баз данных, которым 1c ходит в базу, полные права на свою базу (включая создание таблиц)?

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

Но мало ли конкретно в этом месте они там навертели что-то типа:


try
  create table depotfiles ...;
except:
  // хм, ну ладно, наверное уже есть такая, проверять не будем
  noop;
select from table depotfiles;