Как исправить ошибку СУБД «Invalid object name #tt1» в 1С:Предприятие 8.3?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При работе в клиент-серверном варианте 1С:Предприятие 8.3 пользователи часто сталкиваются с критическим завершением работы, сопровождающимся сообщением «Ошибка СУБД: Microsoft SQL Server Native Client: Invalid object name #tt1». Эта проблема особенно характерна для платформы версии 8.3.9, но может проявляться и в других релизах. Ошибка возникает внезапно: при формировании отчетов (например, ОСВ), поиске в динамических списках или выполнении фоновых заданий. Проанализируем природу этой ошибки и разберем по шагам проверенные способы её устранения.

Выясняем техническую причину ошибки

Для начала разберемся, что именно происходит на уровне взаимодействия системы 1С и SQL-сервера. Символ # в начале имени объекта (например, #tt1, #tt2) в терминологии MS SQL Server означает локальную временную таблицу. Эти таблицы создаются платформой 1С в базе данных tempdb для промежуточного хранения данных во время выполнения сложных запросов.

Проблема «Invalid object name» означает, что платформа 1С пытается обратиться к временной таблице, которая уже не существует в SQL Server. Проанализируем ситуацию: временная таблица «живет» ровно столько, сколько активно соединение (сессия), в котором она была создана. Если сессия между сервером приложений 1С (процесс rphost) и сервером баз данных (процесс sqlservr) обрывается или сбрасывается, SQL Server мгновенно и автоматически удаляет все связанные с ней временные таблицы.

В версиях платформы 8.3.9 был зафиксирован программный баг (зарегистрированный под номером 10171074), при котором менеджер временных таблиц 1С не успевал корректно отработать разрыв соединения. Система пыталась использовать идентификатор таблицы в новом или восстановленном соединении, где этой таблицы уже физически не было. Это приводило к каскадному падению сеансов пользователей.

Способ 1. Обновление платформы до исправленной версии

Самый правильный и надежный метод решения — установка версии платформы, в которой разработчики 1С официально исправили этот баг. Рассмотрим подробнее, какие релизы являются стабильными в этом контексте:

  1. Ветка 8.3.9: Ошибка была исправлена начиная с версии 8.3.9.2170. Если вы используете релизы 1818, 1850 или 2033, обновление до 2170 является обязательным.
  2. Ветка 8.3.10 и выше: В более современных версиях (8.3.10, 8.3.12 и актуальных 8.3.20+) механизм управления временными таблицами был существенно переработан, и данная проблема в её классическом виде не встречается.

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

Способ 2. Откат на стабильную версию (Downgrade)

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

Рекомендуется использовать релиз 8.3.8.2197 или 8.3.8.2322. Рассмотрим по шагам процедуру отката:

  1. Выполните полную резервную копию базы данных средствами SQL Server.
  2. Установите выбранную версию платформы на сервер и рабочие станции.
  3. В настройках базы в консоли администрирования проверьте режим совместимости. Если после перехода на 8.3.9 вы успели обновить версию режима совместимости в конфигураторе, откат может потребовать его возвращения в прежнее состояние.

Способ 3. Настройка параметров SQL Server и Native Client

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

1. Обновление драйвера SQL Native Client. Ошибка часто возникает при использовании устаревшего драйвера версии 10.0 (от SQL 2008). Рекомендуется установить Microsoft SQL Server Native Client 11.0. В настройках строки соединения на сервере 1С убедитесь, что используется актуальный провайдер.

2. Настройка KeepAlive в реестре. Чтобы предотвратить разрыв «зависших» сессий сетевым оборудованием, установим параметры проверки активности соединений. Рассмотрим пример настройки реестра Windows на сервере 1С и сервере SQL:


[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"KeepAliveTime"=dword:0000ea60 (60000 мс = 1 минута)
"KeepAliveInterval"=dword:000003e8 (1000 мс = 1 секунда)

3. Ограничение MAXDOP. Высокая степень параллелизма при выполнении запросов может приводить к коллизиям в tempdb. Установите параметр Max Degree of Parallelism в настройках SQL Server в значение 1 (для высоконагруженных систем — не более 1/4 от числа ядер процессора).

Способ 4. Изменение параметров кластера 1С

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

Также стоит обратить внимание на механизмы Полнотекстового поиска и Расширений. В некоторых релизах 8.3.9 ошибка #tt1 провоцировалась именно фоновыми заданиями индексации или некорректным вызовом методов из расширений. Попробуйте временно отключить полнотекстовый поиск в административной панели и проверить стабильность системы.

Дополнительная диагностика через Технологический журнал

Чтобы убедиться, что проблема именно в баге платформы, а не в конкретном запросе, проанализируем логи 1С. Настройте файл logcfg.xml для сбора событий EXCP и DBMSSQL. Ищите строки следующего содержания:


<event query="DBMSSQL">
  <property name="all"/>
</event>
<event query="EXCP">
  <property name="all"/>
</event>

Если в логе перед ошибкой Invalid object name #tt1 фиксируется событие -1073741819 (0xC0000005) или внезапный разрыв соединения с кодом HRESULT=80040E37, это прямое подтверждение некорректной работы платформы с кэшем временных таблиц. В этом случае единственным долгосрочным решением остается переход на версию 8.3.9.2170 или выше.

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

← На главную