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

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

Неужели нельзя этого сделать без пересоздания бд? Выгружать и загружать огромный dt-шник не самое приятное занятие.

Я имею в виду конечно, решить проблему с итогами а не поменять _YearOffset, его как раз трогать не хочу.

Просмотрел проблемные регистры в MSSQL, у всех в таблицах итогов (AccumRgT) есть записи от 01.01.1753 0:00:00 (т.е. минимальная дата MSSQL) причем с установленными значениями итога, хотя в соответствующих таблицах таким периодами и не пахнет. Причем следующие месяцы, вроде 01.02.1753 в AccumRgT тоже есть.
Кто-то сможет прокомментировать зачем оно так делает? )

Может попробовать просто очистить таблицы итогов для этих регистров и пересчитать их по новой?

В-общем при физической очистке таблиц с итогами регистров все вроде бы работает - пока пробую на копии базы, итоги полностью пересчитываются (хоть и долго) начиная с года ведения базы, а не с XIX века.

Кто-нибудь может объяснить откуда берутся эти ошибки в итогах, не появятся ли они снова?
А если просто почистить строки итого от 02.01.1753 (как я понимаю, в 01 хранится полный итог, в остальных нули) хотя бы до отмены крепостного права =), не повлияет это на работу регистров?

Проблема один в один на УПП, опиши подробней пожалуйста что сделал и что помоголо. Насколько долго итоги с нуля поднимались?

Здравствуйте, недавно столкнулись с подобной ошибкой, при обновлении платформы 1С 8.1

на 1С 8.2. Конвертация прошла удачно как в центральном узле так и в подчиненных

базах. Однако обмен между этими узлами провести не удавалось. выходила ошибка -

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

нулевым смещением дат". Проблему решили, нашили мы 2 метода проведения обновления

конфигурации:
Метод 1) Выгружаем пакет обмена из центрального узла в подчиненный, Принимаем пакет

обмен в подчиненном узле, он естественно ругается что не удалось провести обновление,

после обмена заходим в sql сервер, открываем список таблиц базы данных, находим

таблицу YearOffSet, меняли значение в ней с 0 на 2000, сворачиваем консоль т.к.

значение потом вернем на место, открываем 1С конфигурацию, обновляем конфигурацию и

базу данных, меняем в sql значение, в таблице YearsoffSet обратно с 2000 на 0,

открываем 1С Предприятие - делаем прочитать/записать изменения. Принимаем пакет

обмена в центральном узле. - этот способ занимал много времени, потому начали поиск

более быстрого решения, в связи с большим количеством подчиненных узлов и

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

используя обработку - отключаем центр узел, что дает возможность сделать загрузку

конфигурации, заходим в sql сервер, открываем список таблиц базы данных, находим

таблицу YearsoffSet, меняли значение в ней с 0 на 2000, сворачиваем консоль т.к.

значение потом вернем на место, открываем 1С конфигурацию, загружаем выгруженную из

центрального узла конфигурацию и обновляем базу данных, после чего меняем в sql

значение, в таблице YearOffSet обратно с 2000 на 0, открываем 1С Предприятие - делаем

прочитать/записать изменения. Принимаем пакет обновления в центральном узле.
Так же возникала ошибка после обновления и попытке авторизоваться под Администратором

- решили сменой значения в поле сотрудник.

А меня на 100%% выручила обработка http://infostart.ru/public/146633/
Я не мог выгрузиться в dt, т.к. база огромная, а места на диске С мало.

Есть способ гораздо проще.

Открываем структуру таблиц, нас интересует таблица общих итогов. У меня называется вот так НастройкиХраненияИтоговРегистраБухгалтерии

Потом находим эту таблицу в SQL и меняем поля _Period на 2001-01-01 00:00:00.000 и _MinPeriod 5999-11-01 00:00:00.000. Записываем запись. Запускаем пересчет итогов и наслаждаемся.