Имя: Пароль:
1C
1С v8
Ошибка СУБД, появляющаяся при ТиИ (реструктуризации) и попытке выгрузить базу в .dt
,
0 igor_1506
 
25.04.19
15:08
Добрый день! Возникает ошибка при выгрузке БД в конфигураторе https://ibb.co/M5kpxKz. База клиент-серверная, платформа 8.3.12.1790, СУБД PostgreSQL Pro 10.6.1
Бэкапы создаются средствами СУБД по расписанию.
Пробовал в "песочнице" развернуть бэкап в более новые версии СУБД и на более новых версиях платформы, ничего не меняется. Кто-нибудь с подобным сталкивался? Что можно сделать?
1 igor_1506
 
25.04.19
15:13
В ЖР единственное что написано: "Ошибка выгрузки файл .dt"
2 H A D G E H O G s
 
25.04.19
15:19
Всегда вызывало умиление вот такая публикация ошибки.
Прям как Стивен Кинг - все вроде раскрыто, но самая интрига - за завесой тайны.
3 igor_1506
 
25.04.19
15:20
(2) Я бы хотел узнать, как еще можно выяснить причину этой ошибки?
4 H A D G E H O G s
 
25.04.19
15:27
(3) Верная же ссылка в яндексе
http://dr2c.blogspot.com/2018/11/posgresql-1-mssql.html
5 igor_1506
 
25.04.19
15:39
(4) Так и знал, что мне здесь выложат эту ссылку. Нет никакой таблиц configcas и  configcassave. Это не актуально.
6 H A D G E H O G s
 
25.04.19
15:56
В MS SQL я бы профайлером собрал трассу по посмотрел таблицу на которой спотыкается. Что скажут адепты postgree ?
7 Вафель
 
25.04.19
15:58
(6) в постгре тоже есть профайлер, конечно не такой навороченный, но все навороты то и не нужны
8 igor_1506
 
25.04.19
16:01
(7) Как можно им воспользоваться? Мне бы хоть понять, о какой таблице идет речь. А то ничего не написано.
9 Cyberhawk
 
25.04.19
16:03
Расширения?
10 Сияющий в темноте
 
25.04.19
16:04
напиши скрипт и в копии проселекти все таблицы полным сканированием,сразу станет ясно.
11 igor_1506
 
25.04.19
16:08
(10) Можно подробнее?)) Какой скрипт?
12 igor_1506
 
25.04.19
16:09
(9) Одно расширение было, я его удалял, после этого ничего не меняется.
13 igor_1506
 
25.04.19
16:09
(12) То есть запускал на всякий тестирование (реструктуризацию), все равно ошибка в конце.
14 bolero
 
25.04.19
16:23
(0) в журнале pgsql посмотри FROM откуда конкретно она пытается сделать SELECT (при необходимости log_statement = 'all')

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

возможно, база перекочевала из PG-9 в PG-10 и с тех пор с ней никаких операций выгрузки-загрузки не производили:
8.3.13.1644 и PosgreSQL: ошибка "variable not found in subplan target lists"
15 igor_1506
 
25.04.19
16:27
(14) Был раньше MSSQL. Затем базу загрузили на Linux-сервер, где уже была PostgreSQL. Есть у меня информация, что эту базу восстанавливали из бэкапа средствами СУБД. Но с чего именно все началось я не знаю((
16 igor_1506
 
25.04.19
16:28
(15) PostgreSQL с самого начала была 10.6.1
17 bolero
 
25.04.19
17:32
(15) (16) хорошо, значит в mssql была такого же формата база, без колонки filename

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

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


либо хотя бы скажи название таблицы, в которую добавили колонку FileName, т.к. я ее название забыл сразу же после того, как свою проблему решил
18 igor_1506
 
25.04.19
17:34
(17) В том-то и дело, я не могу найти название этой таблицы, даже не знаю как. Журнал psql как можно посмотреть?
19 igor_1506
 
25.04.19
17:39
(17) Простите, я похоже неверно выразился, а меня неправильно поняли) Базу с MSSQL в PostgreSQL переносили обычной выгрузкой/загрузкой dt
20 igor_1506
 
25.04.19
17:40
Но однажды, уже на Linux-сервере пришлось восстановить базу из бэкапа.
21 bolero
 
25.04.19
17:45
В postgresql.conf: log_statement = 'all'
перезапуск postgres

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

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

grep -i filename xxx.log

как найдешь - log_statement обратно в none и перезапуск, иначе весь диск засрет
22 igor_1506
 
27.04.19
14:54
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 ?
Что можно попробовать сделать в такой ситуации?
23 ansh15
 
27.04.19
18:34
Создал пустую ИБ, в консоли администрирования сервера приложений.
В списке таблиц PostgreSQL таблица depotfiles присутствует, пустая. Структура у нее такая же как и у других таблиц Хранилища поименованных двоичных данных (файлов) (config, configsave и т.д.). В *.dt выгружается без ошибок.
Удалил руками таблицу - drop table depotfiles;
Выгружается в *.dt и загружается назад тоже нормально, может быть из-за того, что таблица была пустой.
Потом сделал реструктуризацию таблиц ИБ(ТиИ), таблица depotfiles появилась в списке.
(22) Попробуйте реструктуризацию, хотя если в вашей базе эта таблица была непустой, может ничего и не даст.
24 igor_1506
 
27.04.19
18:45
(23) Реструктуризация заканчивается той же ошибкой, описанной в (0)
25 H A D G E H O G s
 
27.04.19
18:46
Создайте пустую таблицу depotfiles я думаю, это решит вашу проблему
26 bolero
 
29.04.19
10:13
(22) а есть ли у пользователя баз данных, которым 1c ходит в базу, полные права на свою базу (включая создание таблиц)?

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

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


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