Добрый день!
1С:Предприятие 8.1 (8.1.11.67)
БД крутится на SQL
При загрузке данных в подчиненный узел выдает ошибку
Ошибка СУБД: Microsoft OLE DB Provider for SQL Server: Invalid character value for cast specification. HRESULT=80040E21
И это только в одной базе, все остальные 93 базы загрузились успешно без ошибки.
В файле XML недопустимых символов нет, проверял стандартной обработкой.
Может кто-то сталкивался с данной проблемой, помогите.
Заранее благодарен!
Полная версия этой страницы: Ошибка hresult=80040e21
Украинский 1С форум: всё про 1С 8.3, 1С 8.2, 1С 8.1, 1С 8.0, 1С 7.7 > Администратору 1С / Системному администратору / Администратору баз данных > Администрирование и настройка 1С
Сделать тестирование базы не предлагать?
Цитата(Vofka @ 02.10.12, 13:08) необходимо зарегистрироваться для просмотра ссылки
Сделать тестирование базы не предлагать?
Делал полную проверку, не помогло.
Если база не большая, попробуйте выгрузить её в файловую и попробовать загрузить туда.
Цитата(Vofka @ 02.10.12, 13:29) необходимо зарегистрироваться для просмотра ссылки
Если база не большая, попробуйте выгрузить её в файловую и попробовать загрузить туда.
Сейчас как раз делаю бекап базы.
Бэкапы? Так не интересно. 
Цитата(Vofka @ 02.10.12, 13:34) необходимо зарегистрироваться для просмотра ссылки
Бэкапы? Так не интересно.
Я не могу выкинуть 60 человек что-бы выгрузить из нее ДТшник. вот буду с бекапа делать.
Вообще-то это была шутка юмора. Бэкапы обязательно!
Теперь в файловой базе выдает ошибку {Обработка.ОбменСФилиалами(101)}: Ошибка при вызове метода контекста (ПрочитатьИзменения): Номер года в литерале типа 'Дата' превышает 3999.
Вот. Ну так теперь то хоть по русски пишет шайтан машина. Ищите в хмл-е год больше 3999.
Цитата(Vofka @ 02.10.12, 13:53) необходимо зарегистрироваться для просмотра ссылки
Вообще-то это была шутка юмора. Бэкапы обязательно!
БЭКАПы придумали трусы
Цитата(alex040269 @ 02.10.12, 15:01) необходимо зарегистрироваться для просмотра ссылки
БЭКАПы придумали трусы
Ага. А ещё есть те, кто делает бэкапы и те, кто уже делает бэкапы
.
Проблема была в ПКО, по ошибки сотрудники внесли год 7198.
Всем спасибо за помощь!
Всем спасибо за помощь!
Блин, о чем думали разрабы SQL. Оглянуться не успеешь - а уже на носу будет проблема 4000 года.
Цитата(Ardi @ 02.10.12, 16:43) необходимо зарегистрироваться для просмотра ссылки
Блин, о чем думали разрабы SQL. Оглянуться не успеешь - а уже на носу будет проблема 4000 года.
Та куда там 4000 год, тут уже паспорта выдают 7198 годом
необходимо зарегистрироваться для просмотра ссылки
Цитата
2. Короткий пересказ мыслей разработчиков " Литерал ДАТАВРЕМЯ(1, 1, 1) адекватно представляется на всех СУБД и считается нулевой датой. Даты от ДАТАВРЕМЯ(1, 1, 1, 0, 0, 0) до ДАТАВРЕМЯ(1, 1, 1, 23, 59, 59) считаются временем без даты и тоже адекватно интерпретируются на всех СУБД. Различное поведение возможно для дат из диапазона с ДАТАВРЕМЯ(1, 1, 2) по ДАТАВРЕМЯ(1752, 12, 31, 23, 59, 59). Эти даты не могут быть представлены на MS SQL Server с нулевым смещением дат и могут интерпретироваться либо как нулевые даты, либо вызывать ошибку операций над данными.
В результате можно получить ошибку вроде Microsoft OLE DB Provider for SQL Server: Adding a value to a 'datetime' column caused overflow. HRESULT=80040E07, SQLSrvr: Error state=1, Severity=10, native=517, line=1
3. И хотя официальная позиция 1С туманна, не стоит искать приключения ...
Выбирайте смещение 2000.
В результате можно получить ошибку вроде Microsoft OLE DB Provider for SQL Server: Adding a value to a 'datetime' column caused overflow. HRESULT=80040E07, SQLSrvr: Error state=1, Severity=10, native=517, line=1
3. И хотя официальная позиция 1С туманна
, не стоит искать приключения ...Выбирайте смещение 2000.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.