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

← На главную

Работа с внешними источниками данных (ВИД) в 1С — это мощный инструмент, позволяющий интегрировать учетную систему с сайтами, сторонними базами данных и другими информационными системами напрямую на уровне СУБД. Однако иногда разработчики сталкиваются с загадочной ошибкой: «В схеме базы данных нет таблицы с именем EDBT...». Особенно неприятно то, что чтение данных может работать исправно, а ошибка возникает именно в момент попытки записи или изменения записи. Разберем детально природу этой проблемы и способы её окончательного решения.

Что такое таблицы EDBT и почему они пропадают?

Прежде чем переходить к лечению, проанализируем ситуацию и поймем, что скрывается за аббревиатурой EDBT. Внутренние механизмы платформы 1С:Предприятие для обеспечения связи с внешними таблицами создают в основной базе данных (на стороне MS SQL, PostgreSQL или иной СУБД) специальные служебные таблицы с префиксом EDBT (External Data Base Table). Эти таблицы хранят описание структуры внешних сущностей, сопоставление типов данных и индексы.

Когда мы выполняем запись во внешний источник, 1С обращается к своим системным таблицам (Config, Params), чтобы найти соответствие между объектом метаданных в конфигураторе и физической таблицей EDBT. Если в результате сбоя, динамического обновления или некорректной работы кеша 1С «забывает» это соответствие или пытается обратиться к таблице, идентификатор которой изменился, мы получаем ошибку. Рассмотрим пошагово, как восстановить эту связь.

Шаг 1: Исключение влияния динамического обновления

Одной из самых частых причин «рассинхрона» метаданных является использование динамического обновления конфигурации (так называемого «обновления по F7»). Рассмотрим, почему это критично для внешних источников:

При динамическом обновлении платформа пытается подменить структуру объектов «на лету» для новых сеансов, сохраняя старую для текущих.
Для внешних источников данных это часто приводит к тому, что старый сеанс пытается использовать новую структуру служебных таблиц EDBT, которой еще физически нет, либо наоборот.
В результате идентификатор таблицы в системном кэше перестает соответствовать реальности.

Рекомендация: Если вы активно работаете с внешними источниками данных, забудьте о динамическом обновлении. Выполняйте только полное обновление конфигурации базы данных с завершением всех активных сеансов пользователей.

Шаг 2: Очистка серверного и клиентского кеша

Проанализируем ситуацию с кешированием. Платформа 8.3.12 и выше активно кеширует структуру метаданных. Если ошибка «застряла» в памяти сервера, даже перезапуск службы не всегда помогает. Выполним глубокую очистку:

Остановите службу сервера 1С:Предприятия.
Перейдите в каталог данных сервера (обычно это C:\Program Files\1cv8\srvinfo).
Удалите содержимое папок snccntxt и config внутри папок конкретных информационных баз (папки с именами-GUID).
Очистите локальный кеш на компьютере разработчика (папки в %AppData%\1C\1cv8).
Запустите службу сервера и проверьте результат.

Шаг 3: Настройка драйверов ODBC и параметров подключения

Часто проблема кроется в «общении» 1С с драйвером внешней базы данных. Выясним причину в настройках драйвера. Если ваш внешний источник — это MySQL или PostgreSQL, обратите внимание на следующие моменты:

При использовании MySQL ODBC Driver важно правильно выставить флаги в настройках системного DSN (через odbcad32.exe):

Включите флаг Return matched rows instead of affected rows (вкладка Cursors/Results). Это критично для транзакционной записи, так как 1С должна точно знать, что строка была найдена, прежде чем подтвердить транзакцию.
Убедитесь, что используете версию драйвера Unicode, если в базе есть кириллица.

Рассмотрим пример правильной строки соединения, которую можно прописать программно, чтобы избежать проблем с настройками DSN на разных серверах кластера:


ПараметрыСоединения = Новый ПараметрыСоединенияВнешнегоИсточникаДанных;
ПараметрыСоединения.СтрокаСоединения = "DRIVER={MySQL ODBC 8.0 Unicode Driver};Server=my_site_db;Database=site_db;Uid=admin;Pwd=password;STMT=SET NAMES 'utf8';";
ВнешниеИсточникиДанных.ИмяВашегоИсточника.УстановитьОбщиеПараметрыСоединения(ПараметрыСоединения);

Шаг 4: Проверка режима совместимости и прав доступа

Выясним, не ограничивает ли нас сама платформа. Запись во внешние источники данных была полноценно реализована, начиная с версии 8.3.5. Если ваша конфигурация находится в режиме совместимости с более ранними версиями (например, 8.2.16 или 8.3.4), функционал записи может работать крайне нестабильно, вызывая ошибки отсутствия таблиц EDBT.

Что нужно сделать:

Проверьте свойство конфигурации РежимСовместимости. Рекомендуется устанавливать значение не ниже «8.3.6».
Проверьте права пользователя в сторонней СУБД. Для корректной генерации метаданных 1С требуется доступ к системным таблицам схемы (например, INFORMATION_SCHEMA). Если у пользователя базы сайта есть права только на SELECT/INSERT в конкретной таблице, 1С может не «увидеть» структуру и выдать ошибку EDBT.

Шаг 5: Процедура «Глубокой реинкарнации» источника

Если стандартные методы не помогают и ошибка EDBT продолжает преследовать (как описывает автор темы: «удаляю таблицу, добавляю заново — меняется только номер»), значит, записи о «битых» объектах прочно засели в таблице Config основной базы. Выполним процедуру полной перерегистрации:

Удаление: Полностью удалите проблемную таблицу (или весь внешний источник, если таблиц немного) из дерева метаданных в конфигураторе.
Фиксация: Выполните «Обновить конфигурацию базы данных» (F7).
ТиИ: Запустите «Тестирование и исправление». Обязательно выберите пункты:
- Проверка логической целостности конфигурации.
- Очистка неиспользуемых объектов.
- Сжатие таблиц базы данных.
Восстановление: Заново добавьте внешний источник данных и импортируйте таблицы. Это заставит платформу сгенерировать совершенно новые записи в системных таблицах с чистого листа.

Шаг 6: Особенности SQL Server (Snapshot Isolation)

Проанализируем ситуацию на уровне блокировок. Если основная база 1С работает на MS SQL Server, при записи во внешние источники может возникнуть конфликт блокировок в момент обращения к служебным таблицам EDBT. 1С начинает транзакцию в основной базе и одновременно пытается модифицировать данные во внешней. В некоторых случаях это приводит к тому, что система «теряет» видимость таблицы EDBT внутри транзакции.

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


ALTER DATABASE [Имя_Вашей_Базы_1С] SET ALLOW_SNAPSHOT_ISOLATION ON;
ALTER DATABASE [Имя_Вашей_Базы_1С] SET READ_COMMITTED_SNAPSHOT ON;

Это позволит платформе более гибко работать со служебными таблицами в многопользовательском режиме и при активной работе с внешними данными.

Подводя итог, можно сказать, что ошибка с таблицами EDBT — это почти всегда следствие нарушения целостности кэша или неудачного динамического обновления. Регулярная очистка серверных временных файлов и использование актуальных ODBC-драйверов сводят вероятность появления этой проблемы к минимуму.