Как исправить ошибку СУБД «column "filename" does not exist» при выгрузке базы 1С в .dt и реструктуризации на PostgreSQL

При администрировании клиент-серверных баз данных «1С:Предприятия» на СУБД PostgreSQL системные администраторы иногда сталкиваются с неприятной проблемой. При попытке выполнить выгрузку информационной базы в файл резервной копии .dt или во время проведения реструктуризации таблиц в рамках Тестирования и исправления (ТиИ) процесс прерывается критической ошибкой СУБД. При этом в журнале регистрации 1С отображается лишь лаконичное сообщение: «Ошибка выгрузки файл .dt», а сама СУБД выдает ошибку отсутствия колонки: ERROR: column "filename" does not exist.

В этой статье мы подробно разберем, почему возникает эта ошибка, при чем здесь особенности миграции баз данных с MS SQL Server на PostgreSQL, за что отвечает системная таблица depotfiles и как пошагово решить эту проблему без потери данных.

Выясняем причину: регистрозависимость PostgreSQL и системные таблицы 1С

Для начала давайте разберем внутреннюю архитектуру СУБД. В платформе 1С существует группа системных таблиц, предназначенных для хранения двоичных данных и метаданных конфигурации. К ним относятся такие таблицы, как config, configsave, params, а также интересующая нас таблица depotfiles.

Таблица depotfiles используется платформой 1С при работе с Хранилищем конфигурации (системой групповой разработки). В ней кэшируются служебные файлы версий хранилища. Даже если ваша база данных в текущий момент не подключена к хранилищу конфигурации напрямую, платформа все равно обращается к этой таблице во время операций экспорта структуры (в файл .dt) или при полной реструктуризации базы данных.

Почему же возникает ошибка column "filename" does not exist? Корни проблемы чаще всего кроются в особенностях переноса базы данных с MS SQL Server на PostgreSQL:

1. Чувствительность к регистру (Case Sensitivity). В MS SQL Server имена таблиц и колонок по умолчанию нечувствительны к регистру. В PostgreSQL ситуация иная. Если при создании таблицы или колонки их имена были обернуты в двойные кавычки (например, "FileName"), СУБД сохраняет их именно в таком CamelCase-виде. Если же обратиться к СУБД с запросом без кавычек, например, SELECT FileName FROM DepotFiles, то PostgreSQL автоматически приведет все имена к нижнему регистру и попытается выполнить запрос SELECT filename FROM depotfiles.
2. Последствия некорректной миграции. Если база переносилась с MS SQL Server на PostgreSQL не штатным механизмом выгрузки/загрузки .dt, а сторонними утилитами миграции схем данных или «сырым» восстановлением таблиц, структура служебных таблиц могла нарушиться. Колонки могли создаться в СУБД в верхнем или смешанном регистре внутри кавычек, из-за чего стандартные запросы платформы 1С больше не могут их обнаружить.

Проанализируем детально по шагам, как локализовать и устранить эту неисправность.

Шаг 1. Включение подробного логирования в PostgreSQL

Если вы столкнулись с ошибкой выгрузки, но не уверены, какая именно таблица дает сбой, нам необходимо заставить СУБД записывать все выполняемые запросы в лог-файл. Для этого выполним следующие действия:

1. Найдем конфигурационный файл СУБД postgresql.conf. Обычно в ОС Linux он располагается по пути /var/lib/pgpro/data/ или /etc/postgresql/, а в ОС Windows — в каталоге установки СУБД в папке data.
2. Откроем этот файл текстовым редактором и найдем параметр log_statement.
3. Изменим его значение следующим образом:

log_statement = 'all'

1. Сохраним файл конфигурации и перезапустим службу PostgreSQL, чтобы применить изменения.

Внимание! Режим логирования всех запросов сильно нагружает дисковую подсистему СУБД и быстро заполняет свободное место на диске. Используйте его только на время диагностики и обязательно отключите после решения проблемы!

Шаг 2. Воспроизведение ошибки и анализ технологических логов СУБД

Теперь запустим Конфигуратор 1С:Предприятия и попытаемся повторно выполнить выгрузку информационной базы в файл .dt. Дождемся момента, когда процесс аварийно прервется с ошибкой СУБД.

Перейдем в каталог логов PostgreSQL (папка log или pg_log в директории данных СУБД) и откроем самый свежий файл лога. Выполним поиск по ключевому слову filename или названию ошибки. Мы должны увидеть строку, аналогичную следующей:

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, запрашивая поле FileName, но СУБД PostgreSQL рапортует о том, что колонка filename (в нижнем регистре) в таблице отсутствует или недоступна из-за нарушения структуры.

После фиксации этой информации вернем параметр log_statement в файле postgresql.conf в исходное значение none и снова перезапустим службу СУБД, чтобы предотвратить переполнение диска логами.

log_statement = 'none'

Шаг 3. Исправление структуры таблицы depotfiles в СУБД PostgreSQL

Поскольку реструктуризация средствами самой платформы 1С падает с ошибкой, нам придется вмешаться в структуру базы данных напрямую через консоль администрирования СУБД (например, с помощью утилиты pgAdmin или командной строки psql).

Для исправления ситуации нам нужно пересоздать таблицу depotfiles с корректной структурой, где все имена колонок будут написаны строго в нижнем регистре и без использования экранирующих двойных кавычек.

Давайте разберем по шагам SQL-скрипт для решения этой задачи. Подключимся к нашей базе данных под учетной записью суперпользователя или владельца базы 1С и выполним следующий скрипт:

-- 1. Удаляем старую проблемную таблицу, если она существует
DROP TABLE IF EXISTS depotfiles;

-- 2. Создаем таблицу заново с корректным приведением колонок к нижнему регистру
CREATE TABLE depotfiles (
    filename character varying(128) NOT NULL,
    creation timestamp without time zone,
    modified timestamp without time zone,
    attributes numeric(5,0),
    datasize numeric,
    binarydata bytea,
    partno numeric NOT NULL,
    CONSTRAINT depotfiles_pkey PRIMARY KEY (filename, partno)
);

-- 3. Назначаем владельцем таблицы пользователя, под которым сервер 1С подключается к базе
ALTER TABLE depotfiles OWNER TO имя_пользователя_1с;

В этом скрипте обратите особое внимание на конструкцию первичного ключа depotfiles_pkey, который создается как составной по полям (filename, partno). Поле partno отвечает за номера частей файлов, что критически важно для платформы 1С начиная с версии 8.3 для корректного разбиения и хранения больших двоичных данных (файлов размером более 1 ГБ).

Шаг 4. Очистка кэша сервера и финальная проверка

После успешного выполнения SQL-скрипта в СУБД выполним обязательные процедуры по очистке кэша платформы, чтобы избежать сбоев из-за устаревших планов запросов:

1. Остановим службу сервера «1С:Предприятие».
2. Полностью очистим кэш конфигурации на сервере приложений 1С (удалим папки кэша внутри каталога C:\Users\<Имя_Пользователя>\AppData\Local\1C\1Cv8\ на ОС Windows или аналогичные каталоги в /home/usr1cv8/.1cv8/ на Linux).
3. Запустим службу сервера «1С:Предприятие».
4. Откроем информационную базу в режиме Конфигуратора.
5. Запустим операцию «Администрирование» -> «Выгрузить информационную базу...» и проверим корректность создания файла .dt.

Как показывает практика, после ручного пересоздания структуры таблицы depotfiles выгрузка в .dt и последующие операции реструктуризации таблиц при обновлении конфигурации проходят в штатном режиме без каких-либо ошибок СУБД.