В процессе эксплуатации или миграции баз данных 1С:Предприятие 7.7 на SQL-сервер администраторы часто сталкиваются с ситуацией, когда некорректные данные (например, документы с «будущей» датой вроде 6856 года) блокируют нормальную работу конфигуратора. Проблема проявляется в невозможности зайти в режим «Загрузка данных» или в бесконечном «Пересчете ссылок», который зависает из-за невозможности SQL-сервера или драйвера ODBC обработать аномальное значение. Разберем детально, как выйти из этого тупика, очистить базу или исправить поврежденные записи.
Рассмотрим природу возникновения ошибки. В версии 7.7 для SQL данные хранятся в таблицах, где даты часто представлены в виде строковых полей или специфических форматов. Однако при выполнении административных операций (таких как пересчет ссылочной целостности или реиндексация) система может пытаться интерпретировать эти строки как стандартные типы DATETIME. Поскольку минимальная дата в Microsoft SQL Server — 1 января 1753 года, а максимальная ограничена 9999 годом, значения вне этого диапазона или просто логически неверные даты (ввод опечатки пользователем) могут приводить к сбоям драйвера ODBC.
Ситуация осложняется тем, что при неудачной попытке загрузки 1С выставляет флаг «незавершенной операции». При каждом следующем входе система пытается завершить начатое, попадая в бесконечный цикл. Проанализируем, как разорвать этот круг.
Если «Enterprise Manager» или «SQL Server Management Studio» не позволяют открыть таблицу визуально (выдавая ошибку при попытке отобразить строки), мы можем воспользоваться мощью T-SQL. Основные сведения о документах в 1С 7.7 хранятся в таблице общего журнала — _1SJOURN. Дата там хранится в поле DATE_TIME_IDDOC в виде строки, где первые 8 символов — это дата в формате ГГГГММДД.
Выполним последовательность действий для поиска и исправления проблемной записи:
SELECT *
FROM _1SJOURN
WHERE LEFT(DATE_TIME_IDDOC, 8) > '20500101';
Проанализируем результат. Если мы нашли документ с датой «68560101...», мы можем либо удалить его, либо исправить на корректную дату. Для исправления (например, на 2023 год) используем следующую конструкцию:
UPDATE _1SJOURN
SET DATE_TIME_IDDOC = STUFF(DATE_TIME_IDDOC, 1, 4, '2023')
WHERE LEFT(DATE_TIME_IDDOC, 8) > '20500101';
Важно: После ручного изменения данных в SQL обязательно запустите «Тестирование и исправление» в Конфигураторе 1С, чтобы синхронизировать внутренние индексы программы.
Если данные в SQL-базе безнадежно испорчены или ваша цель — просто перезалить исправную выгрузку (файл .zip), необходимо полностью очистить структуру таблиц. Простого удаления файлов в каталоге базы на диске недостаточно, так как таблицы живут внутри SQL-сервера.
Рассмотрим самый быстрый способ «обнуления» базы без удаления самой оболочки БД в SQL:
Single User Mode или перезапустить службу SQL._, SC (справочники), DH/DT (документы), AC (счета).Простейший способ — сгенерировать список DROP TABLE команд:
DECLARE @sql NVARCHAR(MAX) = N'';
SELECT @sql += 'DROP TABLE ' + QUOTENAME(name) + ';'
FROM sys.tables
WHERE name LIKE '_%' OR name LIKE 'SC%' OR name LIKE 'DH%' OR name LIKE 'DT%';
EXEC sp_executesql @sql;
После выполнения этого скрипта база станет абсолютно пустой с точки зрения 1С. Теперь при запуске Конфигуратора и выборе пункта «Загрузить данные» система не будет пытаться ничего пересчитывать, так как старых данных больше не существует.
Как упоминалось в сообщениях форума, выгрузка данных 1С 7.7 представляет собой ZIP-архив, внутри которого находится файл 1Cv77.dat (или аналогичный). Это текстовый файл, содержащий все данные базы. Если выгрузка уже содержит ошибку (тот самый 6856 год), загрузка в SQL всегда будет падать.
Разберем, как исправить дату в самом файле:
.dat файл мощным текстовым редактором, способным работать с большими файлами (например, Notepad++ или AkelPad). Использовать стандартный Блокнот не рекомендуется — он может «повесить» систему на больших объемах.После этой манипуляции загрузка в SQL должна пройти без ошибок, так как драйвер ODBC больше не встретит некорректных значений даты.
Если Конфигуратор при входе постоянно начинает «пересчет ссылок» и зависает, это означает, что в каталоге базы или в самой базе остались «флаги» незавершенной транзакции. Выясним причину и устраним ее.
Шаг 1: Удаление временных файлов на диске.
Перейдем в каталог, где лежат файлы 1Cv7.md и 1Cv7.dd. Проверим наличие следующих файлов и удалим их:
1SDBSET.TMP — файл-индикатор процесса реструктуризации или загрузки.*.LCK — файлы блокировок..CDX (в случае SQL они могут создаваться для локальных нужд, хотя основные индексы лежат в SQL).Шаг 2: Очистка флага в таблице 1SSYSTEM.
В SQL-версии 1С 7.7 состояние базы часто отслеживается через таблицу 1SSYSTEM. Посмотрим на поле DBSTATE (или аналогичные флаги состояния). Если там записано значение, отличное от «0», 1С считает, что база находится в процессе изменения. Попробуем обнулить состояние:
UPDATE 1SSYSTEM SET DBSTATE = '0';
Это позволит «обмануть» Конфигуратор и зайти в него для выполнения загрузки данных поверх существующих (или пустых) таблиц.
Чтобы процедура «очистки и перезаливки» не занимала часы, проанализируем настройки самой базы на SQL Server. Критически важно перед началом массовой загрузки данных (Reload) изменить модель восстановления базы данных.
По умолчанию база может находиться в режиме Full Recovery Model. При загрузке миллионов строк лог транзакций (.ldf) мгновенно разрастется и может занять всё дисковое пространство, что приведет к остановке загрузки. Выполним следующие действия:
Full, если вы используете бэкапы логов.Также стоит проверить используемый драйвер ODBC. Для 1С 7.7 на современных ОС рекомендуется использовать классический драйвер «SQL Server», так как «Native Client» более строго относится к типам данных и может выдавать ошибки там, где старый драйвер просто пропустит значение.
Подведем итог: если ваша база 1С 7.7 «застряла» из-за некорректных дат, наиболее эффективным путем будет либо точечное исправление даты через UPDATE _1SJOURN, либо полная очистка таблиц скриптом DROP TABLE с последующей загрузкой исправленного .dat файла. Эти методы позволяют восстановить работоспособность системы без необходимости пересоздавать всю базу данных целиком в консоли SQL.