вообщем пытались умельцы обновиться на новый релиз, что-то пошло не так, обновление отметили, но через пару дней обнаружилось, что пропали некоторые объекты: Реализация,сч/ф, счет

битых ссылок в самой конфигурации найти не могу, но в журнале регистрации остались ссылки такого вида
<Не определено 588898f4-c91b-41d4-98b4-b3094396273b>

Пыталась их в каком-то виде всунуть в GUID82, но не получилось

может кто посоветует

бэкапы не предлагать?

(1) "они будут делать бэкапы" © :)
зы. видимо, нет в наличии.. это-ж первым делом надо сделать..

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

обычно в таких случаях пользовалась обработкой поиска и воостановления ссылок , но в таком формате она воспринимть не хочет

она просит объект не найден, но там вид ссылки другой

(3) Раз в год делаете?)))
Какие объекты, куда пропали, что делали, Вы там вообще кто? Я из всего понял, что вашей фирме плохо.

(3) бэкап надо делать перед обновлением..

а сейчас - только одно - посадить бушечек, за день восстановят БД

(4) там? в лесу? она? баба яга?

Поднимайте бакап в резервной базе, перекачивайте туда новую инфу, поднимайте в качестве рабочей, как все перекачаете.

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

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

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

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

-Доктор, меня игнорируют.
-Следующий.

(0) А почему у вас пол не указан? И где фото?

(13) Думаешь, пойдет на такую жертву ради любимой конторы?

+(0) Сделай копию из Архива.
Подсунь лог в Архивную БД.
Под смотри, что за "Битые" ссылки.

Может так быть, что не чего не пропало.
У документов есть еще Регистры, по сути сам документ мало что значит в нормально БД :)

(7) она- имела ввиду обработку guid82, которая ищет и восстанавливает объекты типа объект не найден

(16) Читай в (15), немного думай.
Не придумается, позови спеца :)

"битых ссылок в самой конфигурации найти не могу, но в журнале регистрации остались ссылки такого вида
<Не определено 588898f4-c91b-41d4-98b4-b3094396273b> "

Так это, "а был ли мальчик?". Такие сообщения нормальны при обычном удалении документов или элементов справочника ( не пометка, а именно удаление)

(18) Или мальчик с РЛСом накосячил

может действительно или до обновления удаляли непосредственно, или уже после?

поднять бекап и посмотреть там ЖР однозначно стоит.

Если "пропажу заметили спустя пару дней", то подождут еще пару дней, пока вы развернете бекап и обработкой перенесете то, чего нет в рабочей базе.

(21) вопрос КАК вычислить того,что нет

(15) Спасибо , дельный совет.попробую

Я вот тоже не понял, что именно и кем обнаружилось: <<но через пару дней обнаружилось, что пропали некоторые объекты: Реализация,сч/ф, счет >>
Похоже, что кто-то обнаружил для себя, что работал пару дней в копии базы, а виноват "мальчик", который обновлял.

(24) никто в копии не работал, пропали документы из рабочей базы после неудачной попытки обновления

Без фото не взлетит, да

Если обновление было неудачным, почему в тот же момент не восстановились из бэкапа?
Если побыстрому:
Можно из рабочей базы взять УИД и попробовать в копии базы найти. Потом универсальным обменом перенести объект из копии в рабочую...

Если по правильному:
Поднять бэкап и залить в него то, что успели вбить и работать в нём.

(25) Как именно это поняли: <<пропали документы из рабочей базы>>?
Развернули архив до обновления, и там есть док "реализация № 132", а в рабочей нет? Или кто-то прибежал, я вчера реализацию делал, вот даже распечатанный док остался, а сегодня в рабочей базе его нет?

(8) +100500

(28) программист сделал 2 архивные копии одна до обновления (днем), в  ней доки есть,и я сделала утром следующего дня , доков уже нет.

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

и УИД из резервной копии не находится в рабочей базе

(30) Доки не удаляются при обновлении, они исчезнуть могут всем классом объектов, но раз это часть документов одного типа - значит имело место банальное удаление документов.

(22) Путем сопоставления реквизитов документов. Для оптимизации необходимо ограничить период выборки.

(19) Кстати да, стоит проверить.

что такое РЛС?

Какие могут быть сценарии?
Программист сделал бекап № 1 и пошел покурить на 10 минут, за это время пользователи ввели порцию документов № 1.
Программист вернулся, сделал бекап № 2 и обновил конфигурацию. Пошел опять курить. Пользователи ввели порцию документов № 2.
Позже программисту пожаловались, что что-то пошло не так. Он откатывает базу из бекапа.
Надо понимать, что порция документов № 2 потеряна (если не делать бекап рабочей базы перед откатом).
Что касается порции документов № 2, то она может быть потеряна если с перепугу (или из-за качества выкуренного) программист откатился до бекапа № 1 (вместо № 2).
Так что думайте, как в бекапе оказались документы, которых нет в рабочей.

РЛС - контроль записей на уровне записи. Типа записи есть, но доступа к ним нет, из-за текущих настроек безопасности.

(36) Ой. Контроль доступа на уровне записи, простите за очепятки.

(35) Тогда пропавших документов не должно быть много. И они строго лимитированы по времени создания.