Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

Срочно: потерялся документ из конфигурации

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

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

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

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

как восстановить документ?
 
 
   Фрэнки
 
1 - 18.01.19 - 08:05
восстановить без бакапов?
   MyNick
 
2 - 18.01.19 - 08:09
Самое страшное, заметили через неделю, уже других догов набили кучу.
Наверное не нужен он, раз через неделю заметили )))
   shuhard
 
3 - 18.01.19 - 08:09
(0)[ Очень срочно]
чё так ?
   Повелитель
 
4 - 18.01.19 - 08:11
(0) Поднимаешь бэкап недельной давности,
приводишь к единой конфигурации, берешь обработку с ИТС
ВыгрузкаЗагрузкаДанныхXML.epf
Переносишь документ из одной базы в другую.
   Повелитель
 
5 - 18.01.19 - 08:12
(0) Если неделя прошло, то о какой срочности может быть речь?

Или там просто какому-нибудь начальнику надоело ковырять в носу и захотелось срочно в отчетик посмотреть?
   Tornadius
 
6 - 18.01.19 - 08:15
(4) так и собираюсь сделать. только как быть с движениями. Я понимаю,что при слиянии надо учесть изменения во всех регистрах движений документа. но как перенести сами движения? Это док. Распределение ТЗР. их всего 11 штук было. по одному на каждый месяц делали перед закрытием месяца. если доки перепроводить, то по всей базе потяжки пойдут
   Tornadius
 
7 - 18.01.19 - 08:16
(5) именно так.
   shuhard
 
8 - 18.01.19 - 08:20
(6)[как перенести сами движения?]
ВыгрузкаЗагрузкаДанныхXML
   Фрэнки
 
9 - 18.01.19 - 08:20
(6) А ты возьми и проверь. При наличии бакапов сможешь увидеть будет разница или нет. Поднять последнюю копию, где он еще есть и сравнить с текущей копией базы. Если бакапы делались средствами СУБД, то есть шанс, что кроме изменения конфига ничего не изменилось.

Вообще, очень странная ситуация, т.к. нормально связанный с другими объектами документ просто не удалось бы просто так случайно из базы удалить. Конфигурация просто не смогла бы применить себя к базе со ссылками на удаляемый документ.
   Фрэнки
 
10 - 18.01.19 - 08:23
Вангую, что на базу накатили вышедшее недавно обновление типовой, в которой не оказалось связок с удалившимся документом.
 
 Рекламное место пустует
   Tornadius
 
11 - 18.01.19 - 08:29
Бэкапп делался средствами SQL. обновление было стандартным способом, не через сф. накатывался следующий 114 релиз.
Что произошло не понимаю. Пропал док. и его движения из реестров (их 15 включая партионные и бухгалтерские)
   mikeA
 
12 - 18.01.19 - 08:32
(6) В выгрузке загрузке XML можно выбрать документ, указать выгружать с движениями и за какой период.
   Фрэнки
 
13 - 18.01.19 - 08:37
(11) ну вот ты сам себе и ответил.

С учетом реструктуризации базы при обновлении во всем чего можно и нельзя, сложности ситуации - только поднимать бакап перед обновлением, заново обновляться и накатывать уже новые данные в получившийся результат обновления.
   Segate
 
14 - 18.01.19 - 08:39
(0) Если после обновления документ исчез - то новых доков за эту неделю не набивали.
Поднимаешь бэкап в копии, переносишь данные по документу в боевую конфу, а потом переносишь просто копируешь данные из копии в боевую базу выгрузкой загрузкой xml например.
   unregistered
 
15 - 18.01.19 - 08:43
Если обновление делалось через поддержку, то описанная ситуация невозможна. Ведь речь идёт не о каких-то дописках типового объекта, которые при обновлении могли действительно слетать. А о своём отдельном документе, дописанном "сбоку". Каком образом он мог самоудалиться? Я даже допускаю, что он мог перестать быть регистратором для каких-то типовых регистров и каким-то чудом исчезли записи в регистрах, которые он делал (хотя это уже какая-то фантастика).
Что-то автор недоговаривает, ИМХО...
   Фрэнки
 
16 - 18.01.19 - 08:48
(15) ну он пишет выше, что штук 15 типовых регистров потеряли на него ссылку. В принципе, такое возможно, что вкатил новую уже готовую конфигу, а там же еще и УСО наверченное поверх УПП, т.е. не совсем УПП, а существенно забитое всякими УСО подробностями. Упустил. Что в обновлении "не туда развернул".
   Serg_1960
 
17 - 18.01.19 - 08:52
(не совсем в тему)

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

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

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

Это же так просто!
   Tornadius
 
18 - 18.01.19 - 08:52
(14) новые доки других видов: Банк, касса, производство, все остальные.

Я действительно не знаю причину, откуда возник сбой и прошу помочь разобраться
   Serg_1960
 
19 - 18.01.19 - 08:57
(уже уходя) И почему никто не обратил внимание на сообщение автора об ошибке "Ошибка SDBL поле ID имеет тип REF SELF или ROWVersion"?!? Такого рода ошибки говорят о разрушении записей в базе и (как правило) об их удалении.

Автору рекомендую пообъектно сравнить базу с её копией до обновления - возможно не один только этот документ пропал :(
   Tornadius
 
20 - 18.01.19 - 09:02
(19) этим и занимаюсь в данный момент
   Tornadius
 
21 - 18.01.19 - 09:03
Это не может быть физическим разрушением базы? из-за дисковых ошибок например?
   Фрэнки
 
22 - 18.01.19 - 09:05
(17) // Хоть бы кто нибудь, кроме меня, хоть бы раз посоветовал поднять РИБ.
Я хотел :-)

Но решил промолчать. Если бы у него был РИБ и он умел с ним работать, то вероятность возникновения такого топика была бы гораздо меньше.
   Tornadius
 
23 - 18.01.19 - 09:06
Ну не умею, я работать с РИБ, никогда не делал. Сорри.
   МимохожийОднако
 
24 - 18.01.19 - 09:08
(21) Что гадать о причинах? Сейчас надо думать о последствиях и как исправить?
   Фрэнки
 
25 - 18.01.19 - 09:08
(21) А ты вряд ли узнаешь было разрушение таблиц или нет на уровне носителей, если не будешь сравнивать бакапы сделанные средствами самой СУБД или даже на уровне дисков операционной системы. Собственно к проблеме устранения последствий это уже никак не поможет.
   ptiz
 
26 - 18.01.19 - 09:09
(0)
1. Разобраться с текущими ошибками базы (сначала - на копии!)
2. Поднять архив, сделать конфигурацию архива и рабочую - одинаковыми (с нужным документом)
3. Сделать соответствующие узлы в полном плане обмена там и там.
4. В копии - зарегистрировать изменения всех документов нужного вида с движениями (в типовых есть штатные обработки)
5. Выгрузить данные из копии, загрузить в рабочую.
   Повелитель
 
27 - 18.01.19 - 09:13
(6) Этой обработкой (4) и движения можно перенести.
   Повелитель
 
28 - 18.01.19 - 09:13
(27) Там галка есть "Выгружать с документами все его движения"
   Фрэнки
 
29 - 18.01.19 - 09:14
(23) Обрати внимание на мини-инструкцию в (26)

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

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

При подвязывании актуальной базы к обновлению, если все удастся сделать правильно, появится два узла с полным обменом. Практический аналог онлайн-бакапа, но другими средствами.
   Tornadius
 
30 - 18.01.19 - 09:27
Сейчас сделал на битой базе ТИИС но с настройками "Не изменять... " Ошибка SDBL поле ID ... исчезла, но вывалились ссылки на Банковские счета с "неверная ссылка на владельца" как такое исправить. ТИИС с "Создавать объекты" не помогает
   Tornadius
 
31 - 18.01.19 - 09:28
(29) Я никогда не работал с обменами, да и база в бэкапе старой версии
   МимохожийОднако
 
32 - 18.01.19 - 09:30
(31) на будущее..Бэкапы надо делать до и после обновлений. Возможно, при этом не будешь грешить зря на обновления. Потери могли быть и до обновления
   Фрэнки
 
33 - 18.01.19 - 09:33
(32) как бы "ошибки в работе" случаются всегда.
Собственно, к тому и поговорка о том, что за одного битого двух небитых дают.
 
 
   Повелитель
 
34 - 18.01.19 - 09:34
(33) За один потерянный бит, дают 2 раза битой )))
   Tornadius
 
35 - 18.01.19 - 10:19
Справиться с владельцами банковских счетов помогла обработка "Универсальные подбор и обработка объектов" с ИТС


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Рекламное место пустует