Всем привет. Очень срочно. после обновления из конфы исчез один документ. Каким образом это произошло, я не знаю. Конфа УСО  1.3.113.5. Документ самописный, последний раз его трогали в 2010 году. База серверная на платформе 8.2.19.130

Если какие-то средства по восстановлению базы в такой ситуации?

провел тестирование и исправление - вышло сообщение "Ошибка SDBL поле ID имеет тип REF SELF или ROWVersion

Самое страшное, заметили через неделю, уже других догов набили кучу.

как восстановить документ?

восстановить без бакапов?

Самое страшное, заметили через неделю, уже других догов набили кучу.
Наверное не нужен он, раз через неделю заметили )))

(0)[ Очень срочно]
чё так ?

(0) Поднимаешь бэкап недельной давности,
приводишь к единой конфигурации, берешь обработку с ИТС
ВыгрузкаЗагрузкаДанныхXML.epf
Переносишь документ из одной базы в другую.

(0) Если неделя прошло, то о какой срочности может быть речь?

Или там просто какому-нибудь начальнику надоело ковырять в носу и захотелось срочно в отчетик посмотреть?

(4) так и собираюсь сделать. только как быть с движениями. Я понимаю,что при слиянии надо учесть изменения во всех регистрах движений документа. но как перенести сами движения? Это док. Распределение ТЗР. их всего 11 штук было. по одному на каждый месяц делали перед закрытием месяца. если доки перепроводить, то по всей базе потяжки пойдут

(5) именно так.

(6)[как перенести сами движения?]
ВыгрузкаЗагрузкаДанныхXML

(6) А ты возьми и проверь. При наличии бакапов сможешь увидеть будет разница или нет. Поднять последнюю копию, где он еще есть и сравнить с текущей копией базы. Если бакапы делались средствами СУБД, то есть шанс, что кроме изменения конфига ничего не изменилось.

Вообще, очень странная ситуация, т.к. нормально связанный с другими объектами документ просто не удалось бы просто так случайно из базы удалить. Конфигурация просто не смогла бы применить себя к базе со ссылками на удаляемый документ.

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

Бэкапп делался средствами SQL. обновление было стандартным способом, не через сф. накатывался следующий 114 релиз.
Что произошло не понимаю. Пропал док. и его движения из реестров (их 15 включая партионные и бухгалтерские)

(6) В выгрузке загрузке XML можно выбрать документ, указать выгружать с движениями и за какой период.

(11) ну вот ты сам себе и ответил.

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

(0) Если после обновления документ исчез - то новых доков за эту неделю не набивали.
Поднимаешь бэкап в копии, переносишь данные по документу в боевую конфу, а потом переносишь просто копируешь данные из копии в боевую базу выгрузкой загрузкой xml например.

Если обновление делалось через поддержку, то описанная ситуация невозможна. Ведь речь идёт не о каких-то дописках типового объекта, которые при обновлении могли действительно слетать. А о своём отдельном документе, дописанном "сбоку". Каком образом он мог самоудалиться? Я даже допускаю, что он мог перестать быть регистратором для каких-то типовых регистров и каким-то чудом исчезли записи в регистрах, которые он делал (хотя это уже какая-то фантастика).
Что-то автор недоговаривает, ИМХО...

(15) ну он пишет выше, что штук 15 типовых регистров потеряли на него ссылку. В принципе, такое возможно, что вкатил новую уже готовую конфигу, а там же еще и УСО наверченное поверх УПП, т.е. не совсем УПП, а существенно забитое всякими УСО подробностями. Упустил. Что в обновлении "не туда развернул".

(не совсем в тему)

Ну вот почему так всегда: как только поднимать объекты из бэкапа базы - так советы типа "ВыгрузкаЗагрузкаДанныхXML"?

Хоть бы кто нибудь, кроме меня, хоть бы раз посоветовал поднять РИБ.

Всего две записи в план обмена в базе и её копии - и всё! Всё, можно обмениваться данными - документами и их движениями.

Это же так просто!

(14) новые доки других видов: Банк, касса, производство, все остальные.

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

(уже уходя) И почему никто не обратил внимание на сообщение автора об ошибке "Ошибка SDBL поле ID имеет тип REF SELF или ROWVersion"?!? Такого рода ошибки говорят о разрушении записей в базе и (как правило) об их удалении.

Автору рекомендую пообъектно сравнить базу с её копией до обновления - возможно не один только этот документ пропал :(

(19) этим и занимаюсь в данный момент

Это не может быть физическим разрушением базы? из-за дисковых ошибок например?

(17) // Хоть бы кто нибудь, кроме меня, хоть бы раз посоветовал поднять РИБ.

Я хотел :-)
Но решил промолчать. Если бы у него был РИБ и он умел с ним работать, то вероятность возникновения такого топика была бы гораздо меньше.

Ну не умею, я работать с РИБ, никогда не делал. Сорри.

(21) Что гадать о причинах? Сейчас надо думать о последствиях и как исправить?

(21) А ты вряд ли узнаешь было разрушение таблиц или нет на уровне носителей, если не будешь сравнивать бакапы сделанные средствами самой СУБД или даже на уровне дисков операционной системы. Собственно к проблеме устранения последствий это уже никак не поможет.

(0)
1. Разобраться с текущими ошибками базы (сначала - на копии!)
2. Поднять архив, сделать конфигурацию архива и рабочую - одинаковыми (с нужным документом)
3. Сделать соответствующие узлы в полном плане обмена там и там.
4. В копии - зарегистрировать изменения всех документов нужного вида с движениями (в типовых есть штатные обработки)
5. Выгрузить данные из копии, загрузить в рабочую.

(6) Этой обработкой (4) и движения можно перенести.

(27) Там галка есть "Выгружать с документами все его движения"

(23) Обрати внимание на мини-инструкцию в (26)

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

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

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

Сейчас сделал на битой базе ТИИС но с настройками "Не изменять... " Ошибка SDBL поле ID ... исчезла, но вывалились ссылки на Банковские счета с "неверная ссылка на владельца" как такое исправить. ТИИС с "Создавать объекты" не помогает

(29) Я никогда не работал с обменами, да и база в бэкапе старой версии

(31) на будущее..Бэкапы надо делать до и после обновлений. Возможно, при этом не будешь грешить зря на обновления. Потери могли быть и до обновления

(32) как бы "ошибки в работе" случаются всегда.
Собственно, к тому и поговорка о том, что за одного битого двух небитых дают.

(33) За один потерянный бит, дают 2 раза битой )))

Справиться с владельцами банковских счетов помогла обработка "Универсальные подбор и обработка объектов" с ИТС