Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

Ошибка СУБД, появляющаяся при ТиИ (реструктуризации) и попытке выгрузить базу в .dt

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

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

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


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

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

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

grep -i filename xxx.log

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

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

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

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

  noop;
select from table depotfiles;



Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.