Почему при сохранении конфигурации 1С 7.7 SQL происходит долгий пересчет ссылок с 1735 года и как это исправить?

← На главную

При работе с крупными базами данных на платформе 1С:Предприятие 7.7 (SQL-версия) администраторы и программисты часто сталкиваются со странным поведением конфигуратора. В момент сохранения изменений в структуре метаданных система инициирует процесс «Пересчет ссылок по графам отбора», который неожиданно начинается с аномально ранних дат, таких как 1730, 1735 или 1753 год. Это приводит к тому, что сохранение конфигурации может растягиваться на часы, парализуя работу разработчика.

В этой статье мы подробно разберем, почему возникают такие «путешествия во времени», где именно в базе данных прячутся эти записи и как их эффективно устранить с помощью встроенного языка 1С и инструментов SQL.

Выясним причину: почему именно 1753 год?

Прежде всего, проанализируем техническую подоплеку. Дата 01.01.1753 является минимально возможным значением для типа данных datetime в MS SQL Server. Если в процессе записи документа, записи в таблицу периодических реквизитов или при некорректном прямом удалении данных возникают ошибки, 1С может записать в поле даты либо пустое значение (которое SQL интерпретирует как минимальное), либо системный «мусор».

Проблема «всплывает» именно при сохранении конфигурации, так как 1С выполняет реиндексацию и обновление таблиц граф отбора (например, по контрагентам или договорам). Конфигуратор сканирует таблицы в поисках самой ранней даты, чтобы определить границы пересчета, и натыкается на «битую» запись.

Решение 1: Поиск и обработка документов с пустой датой через 1С

Самая распространенная причина — наличие в системе документов, у которых физически отсутствует дата. Несмотря на то что в обычном журнале такие документы могут не отображаться (если установлен фильтр по периоду), они существуют в таблице _1SJOURN.

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


Док = СоздатьОбъект("Документ");
Док.ВыбратьДокументы();
Пока Док.ПолучитьДокумент() = 1 Цикл
    Если ПустоеЗначение(Док.ДатаДок) = 1 Тогда
        Сообщить("Обнаружен проблемный документ: " + Док.ПредставлениеВида() + " № " + Док.НомерДок);
        
        // Вариант 1: Удаление битого документа (рекомендуется, если документ - мусор)
        // Док.Удалить(1); 
        
        // Вариант 2: Установка корректной даты, чтобы объект попал в рабочий диапазон
        Док.ДатаДок = ТекущаяДата();
        Док.Записать();
        
        Сообщить("Документ исправлен.");
    КонецЕсли;
КонецЦикла;

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

Решение 2: Проверка периодических реквизитов (Таблица _1SCONST)

Если перебор документов не принес результатов, нам следует проанализировать историю периодических реквизитов справочников и констант. Информация о них хранится в системной таблице _1SCONST. Часто именно там «застревают» значения с некорректными датами начала действия.

Разберем ситуацию: стандартное «Тестирование и исправление» (ТиИ) может не находить эти ошибки, так как логическая связь со справочником сохранена, но дата записи в SQL-таблице выходит за рамки разумного. В этом случае помогают прямые SQL-запросы.

Решение 3: Использование прямых SQL-запросов для диагностики

Когда база слишком велика для полного перебора средствами 1С, мы можем обратиться к SQL Management Studio. Это позволит мгновенно найти записи-виновники в ключевых таблицах.

Проанализируем основные таблицы, выполнив следующие запросы:

Проверка общего журнала документов:
SELECT * FROM _1SJOURN WHERE DATE < '19000101'

Этот запрос выявит все документы, дата которых меньше 1900 года. Если вы увидите там записи, их IDDOC поможет найти конкретный документ в интерфейсе 1С.
Проверка периодических значений:
SELECT * FROM _1SCONST WHERE DATE < '19000101'

Если здесь обнаружатся записи, это означает, что у какой-то периодической константы или реквизита справочника установлена «древняя» дата.
Проверка таблиц граф отбора:
Таблицы вида _1SCRIT хранят индексы для отборов. Если в них попал идентификатор удаленного объекта с некорректной ссылкой, это также вызовет долгий пересчет.

Решение 4: Комплексная очистка через Тестирование и Исправление

Если точечные исправления не помогают, проанализируем возможности штатного механизма «Тестирование и исправление ключей и данных». Для решения нашей проблемы необходимо запустить процесс со следующими настройками:

Проверка физической целостности: восстанавливает структуру таблиц на уровне БД.
Проверка логической целостности: находит ссылки на несуществующие объекты.
Очищать ссылки: при обнаружении «битых» ссылок на объекты, которых уже нет в базе, 1С удалит записи из индексов граф отбора.

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

Подведем итоги

Проблема пересчета ссылок с 1730-1753 годов — это типичный симптом «грязных» данных в SQL-версии 1С 7.7. Мы выяснили, что основными источниками проблем являются:

Документы с пустыми датами в таблице _1SJOURN.
Записи в таблице _1SCONST с датами, близкими к минимальному порогу SQL Server.
Ошибки в графах отбора (_1SCRIT), вызванные некорректным удалением данных.

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