Ошибка СУБД Column does not exist

21.11.21

В данной статье на примере СУБД Postgre и конфигурации УНФ описывается метод исправления ошибки "Column does not exist". На просторах интернета натыкался на общее описание проблемы, что состав базы со стороны СУБД не соответствует той картине, что ожидает 1С. Надо приводить все в соответствие, а конкретных примеров не находил.

Изначально имеем:

Управление нашей фирмой, редакция 1.6 (1.6.25.212)

Postgre 9.4.2

pgAdmin 4.6.2

Все действия выполняются без активных сеансов с базой (кроме конфигуратора, когда он нужен)

При попытке выгрузки *.dt перед обновлением появилась ошибка, которая указывала на то,что не найдена колонка с обозначенным именем.

Уточнил у системного администратора, копии средствами СУБД делаются успешно, стандартная проверка базы ошибок не дает.

Попытка запуска ТиИ выдала такую же ошибку. Зато в нижней части конфигуратора видно было, какая таблица проверялась, когда получили ошибку с полем. (В принципе, это можно было узнать и средствами СУБД.

Прилагаю пример, как это можно найти в Pg admin 4. Как альтернатива, можно также написать запрос, примера которого у меня нет под рукой)

Далее, используя платформенный метод ПолучитьСтруктуруХраненияБазыДанных(), узнал, на какую таблицу и поле указывает ошибка. В моем случае это был справочник "ДанныеОКорректировкеСведенийЗастрахованныхЛицСЗВ_КОРРПрисоединенныеФайлы" и поле "Редактирует". Справочник пуст, что снимает переживания о потере данных.

После этого полез в СУБД изучать картину.

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

Попытка обычного переименования(через интерфейс 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 и произвести дальнейшие манипуляции с базой.

Следует отметить, что случай этот не страшный.

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

Процессу работы пользователей ошибка не мешала, копии средствами СУБД выполнялись исправно.

Если кто знает более практичные способы решения проблемы - буду рад ознакомиться.

Вступайте в нашу телеграмм-группу Инфостарт

СУБД Администрирование баз данных Ошибка Поле не найдено

+4 –

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

0% комиссии — оплата напрямую исполнителю;
Исполнители любого масштаба — от отдельных специалистов до команд под проект;
Прямой обмен контактами между заказчиком и исполнителем;
Безопасная сделка — при необходимости;
Рейтинги, кейсы и прозрачная система откликов.

См. также

Как запрос 1С замедляет PostgreSQL в 22 раза — и как мы это починили

HighLoad оптимизация Администрирование СУБД Программист Россия Бесплатно (free)

Если вы работаете с 1С на PostgreSQL и жалуетесь на тормоза — скорее всего, дело в join predicate pushdown, которого в стандартном PostgreSQL нет. В MS SQL Server этот механизм работает «из коробки», и при миграции именно запросы к виртуальным таблицам 1С бьют по производительности сильнее всего. В этой статье — реальный кейс от Postgres Professional с разбором плана выполнения, ручным экспериментом и доработкой планировщика СУБД, которая ускорила запросы от 22 до 54 000 раз.

16.06.2026 5805 postgres_professional 13

СУБД Tantor Postgres 18: обзор улучшений для 1С

HighLoad оптимизация Администрирование СУБД Системный администратор Программист 1С:Предприятие 8 Бесплатно (free)

Вышел релиз СУБД Tantor Postgres 18, и мы хотим рассказать о его новых возможностях для работы с приложениями на платформе "1С:Предприятие". В обзоре разберем улучшения планировщика, по традиции коснемся работы временных таблиц и не обойдем вниманием вспомогательные утилиты, которые упрощают поиск и диагностику проблем в высоконагруженных системах. За каждым пунктом - реальные запросы 1С, реальные рабочие базы и сотни часов тестирования!

16.06.2026 849 Tantor 7

Уменьшение размера базы 1С – а нужна ли вообще свертка

Администрирование СУБД Системный администратор Программист 1С:Предприятие 8 Россия Бесплатно (free)

База 1С за несколько лет эксплуатации разрослась, - стала большой, медленно работает, требует много места и времени для копирования и прочего обслуживания. Нужна ли обязательно свертка или можно обойтись более «мягкими» средствами. Делюсь своим опытном как для новых конфигураций, так и для старых УПП, УТ 10…

01.06.2026 5842 2ncom 30

Postgres и 6 ТБ данных: что мы узнали за год эксплуатации

Администрирование СУБД Системный администратор Программист Бесплатно (free)

Статья рассказывает об опыте перевода больших баз с MSSQL на Postgres и годовой эксплуатации после перехода. Показано, с какими ограничениями утилиты ibcmd можно столкнуться при миграции больших баз и какие подходы помогают безопасно обходить эти проблемы. Приведены наиболее интересные кейсы, выявленные в эксплуатации: особенности настроек Postgres, поведение оптимизатора, тонкости работы логики и статистики, а также редкие, но критичные ситуации с производительностью. Материал будет полезен тем, кто планирует переход на Postgres и хочет заранее понимать реальные риски, подводные камни и проверенные практики их преодоления.

20.04.2026 7083 berserg 12