Mazmunga o'tish
Tez Base

Расшифровка ошибки 1С

"Дата '01.02.0001 0:00:00' не может быть записана в базу данных на MS SQL Server с нулевым смещением дат"

Где возникает
База 1С на MS SQL Server, у которой смещение дат 0. Всплывает при записи объекта, пересчёте итогов, загрузке выгрузки dt и обмене. При переносе через ibcmd infobase replicate вместо окна с ошибкой появляется одна строка [WARN] в stderr, а код возврата остаётся 0.
Что значит
Платформа считает датой всё начиная с 01.01.0001, а MS SQL при нулевом смещении принимает даты только с 1753 года. Запись более ранней даты обрывается этой ошибкой, а при переносе дата молча подрезается до 01.01.1753, и две разные даты становятся одной.
Как ещё выглядит этот текст
  • Ошибка в значении типа Дата не может быть записана в базу данных на MS SQL Server с нулевым смещением дат
  • Таблица содержит значения типа Дата, которые не могут быть записаны в MS SQL Server с нулевым смещением дат
  • Таблица v8users содержит значения типа Дата
  • нулевое смещение дат ms sql 1с
  • смещение дат 2000 1с
  • дата 1753 вместо пустой даты 1с

Причины

Причина Как узнать Как часто
Базу перенесли или загрузили в MS SQL со смещением 0 из источника с датами раньше 1753 года В приёмнике запрос к _YearOffset даёт 0, в источнике есть даты раньше 1753 года. У ibcmd в stderr строка [WARN] с именем таблицы встречали сами на стендовом замере
Код или обмен вычисляет дату от пустой: ДобавитьМесяц к 01.01.0001 даёт как раз 01.02.0001 Ошибка возникает на одном объекте или одной операции, а смещение базы 0 стоит давно и раньше не мешало известная причина, у нас не встречалась
Базу создали в кластере или консоли с нулевым смещением, хотя для MS SQL ставят 2000 В _YearOffset ноль у новой базы, в которую ещё ничего не загружали известная причина

Порядок действий

  1. Узнайте смещение базы. Оно хранится в служебной таблице, запрос выполняется в SQL Server Management Studio на базе 1С:
-- 0 значит нулевое смещение, 2000 - штатное для MS SQL
USE YourDb;
SELECT * FROM _YearOffset;

Смещение при регистрации в кластере должно совпадать с этим значением.

  1. Найдите даты раньше границы. Граница считается как 1753 минус смещение, при нуле это 01.01.1753. Запрос в консоли запросов по каждой таблице с датами:
// Сколько дат таблицы не поместится при смещении 0
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ РАЗРЕШЕННЫЕ
|	КОЛИЧЕСТВО(ВЫБОР КОГДА Дата < &Граница ТОГДА 1 КОНЕЦ) КАК ДатРаньшеГраницы,
|	МИНИМУМ(ВЫБОР КОГДА Дата < &Граница ТОГДА Дата КОНЕЦ) КАК МинимальнаяДата
|ИЗ
|	Документ.ВашДокумент";
Запрос.УстановитьПараметр("Граница", Дата(1753, 1, 1));
Результат = Запрос.Выполнить().Выгрузить();

Обход всей базы, включая периоды регистров и составные реквизиты, делает обработка “Проверка базы 1С перед переносом на MS SQL Server”, она ничего не пишет в базу.

  1. Если ошибка пришла с переносом или загрузкой dt, пересоздайте приёмник со смещением 2000 и повторите перенос. У ibcmd infobase replicate за это отвечает параметр --target-date-offset=2000, при загрузке dt смещение задаётся при создании базы в кластере.

  2. Если смещение 0 стоит давно и ошибка падает на одной операции, ищите место, где дата считается от пустой. Типичный след - год 1 в значении: ДобавитьМесяц или НачалоМесяца от пустой даты. Пустую дату проверяйте до расчёта.

  3. Таблицу _YearOffset в базе с данными руками не правьте, почему - в первом вопросе ниже.

Как проверить, что исправлено

Операция, которая падала, проходит. После переноса stderr у ibcmd пустой, _YearOffset в приёмнике равен 2000.

Диапазон дат таблицы на уровне СУБД должен сдвинуться ровно на 2000 лет. На стенде у задетого регистра сведений 0001-01-01 .. 2026-07-20 стало 2001-01-01 .. 4026-07-20:

-- Диапазон периодов регистра в приёмнике
SELECT MIN(_Period) AS min_data, MAX(_Period) AS max_data, COUNT(*) AS strok
FROM _InfoRg31415;

Тот же запрос платформы из шага 2 на источнике и приёмнике обязан дать одинаковые числа. Совпавшее количество строк этого не доказывает. Колонки дат на стенде были datetime2, который год 1 хранит, так что подрезку делает платформа по смещению, и правка типов колонок в SQL не поможет.

Наш случай

Стендовый замер 09.09.2026: тестовая бухгалтерская база, 11 396 таблиц, перенос с PostgreSQL на MS SQL Server 2022 через ibcmd со смещением 0. Прогон вернул код 0, весь stderr уместился в одну строку на 208 байт. В одной таблице 0001-01-01 и 0001-01-02 обе стали 1753-01-01, число строк при этом совпало: 6 и 6. Повтор со смещением 2000 прошёл с пустым stderr.

Полный разбор переноса с PostgreSQL на MS SQL

Похожие ошибки

Переезд на MS SQL упирается в смещение дат или в базе уже лежат подрезанные даты?

До переноса проверяем даты всех таблиц под нужное смещение, репетируем на копии, после сверяем значения.

Narxi
450 000 ₸ danbir martalik sozlash; kuzatib borish - oyiga 150 000 ₸ dan; soliqlarsiz

Yozishga erta? O'zingiz o'lchang

Чек-ап СУБД под 1С: 40+ проверок с вердиктом по каждой

Ishlov berishni ochish

Частые вопросы

Можно ли поменять 0 на 2000 прямо в таблице _YearOffset?

В заполненной базе нельзя. Сами даты от правки не сдвинутся, а читаться все они станут со сдвигом на 2000 лет. Смещение меняют пересозданием базы с нужным значением и повторной загрузкой данных.

Какое смещение ставить для новой базы на MS SQL?

2000. С ним любая дата платформы, включая год 1, попадает в допустимый диапазон. Это же значение ibcmd подставляет для MS SQL сам, если параметр --target-date-offset не трогать.

Перенос завершился успешно, количество строк совпало. Данные целы?

Нет гарантии. На стенде при смещении 0 счётчики совпали по всем шести контрольным таблицам, включая испорченную. Сверяйте минимальную и максимальную дату по таблицам и число пустых дат по реквизитам.

Проверено: 1С 8.3.27, MS SQL Server 2022, сентябрь 2026

Vazifani muhokama qilamiz

Eng tezi WhatsApp: vazifa haqida bir-ikki qator yozing, ish kuni davomida javob beramiz.

[email protected]

Arizani forma orqali qoldirish qulayroq