Как устранить ошибку при обращении к таблицам MySQL с зарезервированными именами через Внешние источники данных

← На главную

При работе с механизмом Внешних источников данных (ВИД) в 1С:Предприятии программисты часто сталкиваются с ситуацией, когда подключение к базе данных MySQL проходит успешно, большинство таблиц читаются корректно, но одна или несколько таблиц вызывают критическую ошибку при попытке выполнить даже самый простой запрос. Типичный пример такой ситуации — таблица с именем ORDER. Разберем подробно, почему это происходит и как решить проблему несколькими способами.

Анализ причины возникновения ошибки

Проблема заключается в том, что слово ORDER является зарезервированным ключевым словом в языке SQL (оно используется в конструкции ORDER BY для сортировки данных). Когда платформа 1С генерирует запрос к внешнему источнику, она формирует стандартный SQL-текст. Если драйвер ODBC или сама СУБД получают запрос вида SELECT ... FROM ORDER, возникает синтаксическая ошибка, так как сервер ожидает после слова ORDER продолжение инструкции, а не использование его в качестве имени таблицы.

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

Решение 1: Создание SQL-представления (View) на стороне MySQL

Проанализируем наиболее надежный и профессиональный способ обхода проблемы. Если вы не можете переименовать таблицу в исходной базе данных (например, если это база популярной CMS сайта, где структура жестко задана кодом движка), оптимальным решением будет создание «зеркала» этой таблицы с корректным именем.

Выполним следующие шаги на стороне сервера MySQL (через phpMyAdmin, MySQL Workbench или консоль):

Создадим представление с нейтральным именем, например, site_orders.
В определении представления выберем все поля из исходной таблицы.

Пример SQL-кода для создания такого представления:


CREATE VIEW site_orders AS 
SELECT * FROM `order`;

После создания представления вернемся в Конфигуратор 1С. Теперь в объекте «Внешний источник данных» при добавлении таблиц мы выбираем не проблемную таблицу order, а наше новое представление site_orders. Для платформы 1С это будет выглядеть как обычная таблица, и конфликт имен исчезнет, так как слово site_orders не является зарезервированным.

Решение 2: Настройка драйвера MySQL Connector/ODBC

Иногда проблему можно решить на уровне настроек связующего звена — драйвера ODBC. В современных версиях драйвера (например, 8.0.x) существуют специальные флаги, управляющие экранированием идентификаторов.

Разберем процесс настройки:

Откроем «Администратор источников данных ODBC» (в соответствии с разрядностью вашей версии 1С, обычно это 32-битная версия).
Найдем наше соединение (DSN) и перейдем в настройки (Configure).
Зайдем во вкладку Details, далее в раздел Flags 3.
Установим галочку Enable identifier quoting.

Если вы формируете строку соединения программно, в нее можно добавить параметр OPTION=1. Этот флаг заставляет драйвер автоматически обрамлять имена таблиц и полей в обратные апострофы (`), что позволяет серверу MySQL однозначно идентифицировать `order` как объект базы данных, а не как команду.

Решение 3: Изменение метаданных во внешнем источнике данных

Посмотрим на возможности самой платформы 1С. В окне свойств таблицы внешнего источника данных есть два важных поля: Имя и Имя в источнике данных.

Попробуем следующий прием:

Поле Имя оставим как ЗаказыСсайта (это внутреннее имя в 1С).
В поле Имя в источнике данных попробуем вручную прописать имя в обратных апострофах: `order`.

Важное замечание: Этот метод срабатывает не всегда, так как некоторые версии платформы могут повторно экранировать уже экранированное имя, что приведет к другой ошибке. Однако в ряде случаев это позволяет быстро решить вопрос без создания представлений в SQL.

Решение 4: Использование прямого запроса через ADODB

Если стандартный механизм ВИД продолжает выдавать ошибку Запрос.Выполнить(), проанализируем альтернативный путь — использование объекта ADODB.Connection. Этот метод позволяет писать «сырой» SQL-код, полностью контролируя синтаксис.

Рассмотрим пример программного обращения к проблемной таблице:


Соединение = Новый COMОбъект("ADODB.Connection");
СтрокаПодключения = "Driver={MySQL ODBC 8.0 Unicode Driver};Server=myServerAddress;Database=myDataBase;User=myUsername;Password=myPassword;Option=3;";

Попытка
    Соединение.Open(СтрокаПодключения);
    RecordSet = Соединение.Execute("SELECT * FROM `order` WHERE status = 1");
    
    Пока RecordSet.EOF() = 0 Цикл
        // Обработка данных
        Сообщить(RecordSet.Fields("id").Value);
        RecordSet.MoveNext();
    КонецЦикла;
    
    Соединение.Close();
Исключение
    Сообщить("Ошибка подключения: " + ОписаниеОшибки());
КонецПопытки;

В данном случае мы вручную экранируем таблицу `order` в тексте запроса, что гарантирует корректное выполнение команды сервером MySQL.

Дополнительные технические нюансы MySQL 8.0

Выясним еще одну возможную причину ошибок, которая часто маскируется под проблемы с именами. В таблицах заказов часто используются типы данных DATETIME. В MySQL версии 8.0 и выше при определенных настройках в полях даты могут содержаться «нулевые» значения (0000-00-00 00:00:00).

1С:Предприятие не поддерживает такие значения дат и выдает ошибку при попытке выгрузить результат запроса. Чтобы этого избежать, в строку подключения (или в настройки DSN) рекомендуется добавить параметры:

NO_DATETIME_CONVERSION=1 — для корректной передачи дат.
CharSet=utf8 или cp1251 — для исключения проблем с кодировкой метаданных.

Подводя итог, можно сказать, что наиболее стабильным решением для долгосрочной эксплуатации является создание SQL View (Представления). Это изолирует логику 1С от особенностей именования в сторонней базе данных и позволяет использовать стандартный конструктор запросов без каких-либо ограничений.