Изначально имеем:
Управление нашей фирмой, редакция 1.6 (1.6.25.212)
Postgre 9.4.2
pgAdmin 4.6.2
Все действия выполняются без активных сеансов с базой (кроме конфигуратора, когда он нужен)
При попытке выгрузки *.dt перед обновлением появилась ошибка, которая указывала на то,что не найдена колонка с обозначенным именем.
Уточнил у системного администратора, копии средствами СУБД делаются успешно, стандартная проверка базы ошибок не дает.
Попытка запуска ТиИ выдала такую же ошибку. Зато в нижней части конфигуратора видно было, какая таблица проверялась, когда получили ошибку с полем. (В принципе, это можно было узнать и средствами СУБД.
Далее, используя платформенный метод ПолучитьСтруктуруХраненияБазыДанных(), узнал, на какую таблицу и поле указывает ошибка. В моем случае это был справочник "ДанныеОКорректировкеСведенийЗастрахованныхЛицСЗВ_КОРРПрисоединенныеФайлы" и поле "Редактирует". Справочник пуст, что снимает переживания о потере данных.
После этого полез в СУБД изучать картину.
Слева проблемная база, справа ее копия для тестирования, развернутая до возникновения проблемы.
Попытка обычного переименования(через интерфейс pgAdmin) выдает ошибку, что поле "_fld28724]rtref" не найдено. Попытка создания правильного поля(скриптом Create) выдает ошибку, что поле "_fld28724_rtref" уже существует.
Ага! т.е. оно есть, но видим мы его иначе.
А вот скрипт
ALTER TABLE IF EXISTS public._reference28250
RENAME COLUMN "_fld28724_rtref" TO "_fld28724__rtref";
Работает успешно. Обновляем дерево объектов в СУБД. Теперь поле отражается, как мы задали ему новое имя. Меняем обратно на исходное.
ALTER TABLE IF EXISTS public._reference28250
RENAME COLUMN "_fld28724__rtref" TO "_fld28724_rtref";
После этого получилось выгрузить копию *.dt и произвести дальнейшие манипуляции с базой.
Следует отметить, что случай этот не страшный.
Сам справочник пустой, поле итак присутствовало, но с некорректным именем. Не было необходимости создавать поле с нуля, сверившись с другой базой или скопировав из нее. Не было необходимости восстанавливать данные.
Процессу работы пользователей ошибка не мешала, копии средствами СУБД выполнялись исправно.
Если кто знает более практичные способы решения проблемы - буду рад ознакомиться.
