В базу загрузили архив другой базы, с другой конфигурацией.
Файлы Sc, Dt, Dh не тронуты, но системные (операционные) файлы такие как 1SJOURN, 1SENTRY и т.д. перезаписаны.
Пробовал обработку restjrn, но она тянет записи из потерянного 1sentry (ничего не выходит).
Пробовал ТИИ результат категорически не устраивает.
Кто что может посоветовать?

Тяни из DH+RA+mlg - если там чего осталось конечно...

бэкапов нема канешно?

RA - нет, - у меня бухгалтерия

(2) про бэкапы - все плачевно

(0) А как это не тронуты, если загрузили другую базу?

(5) структуры баз совсем разные - в новой базы дбф-ки другие (по именам) (они просто новые создались) а вот те, именя которых совпали и перезаписались

(6) попробуй проанализировать DD.
Но если некоторые файлы перезаписались,
то это конец.

Ежели кроме проводок никаких других движений доки не формировали - тогда опаньки. 1SJOURN не восстановишь. Дату дока взять неоткуда.

Судя по всему, прибыло полку тех, кто БУДЕТ делать бэкапы.

забудь

1.Создавай пустую базу + все сохранившиеся справочники.
2.Обработкой по mlg создай пустые документы.
3.Ручное восстановление доков по распечатанной первичке.

Если объем небольшой (а судя по отсутствию бекапов так и есть) - это лучший способ.

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

может что нить из mlg удастся вытащить?

(13) Если mlg полный - то можно ВСЁ вытащить. Там и ссылки есть и последнее состояние дока можно восстановить, если грамотно распарсить.

(0) опупеть. Чего ж мы так архивы то не любим?

(14) смотрю - там за 6 лет записи.
Можешь подсказать его формат
Вот к примеру строка

20100505;11:47:18;Виктория;E;Docs;DocPassed;2;;O/551/24753;Плат.пор. 121 05.05.2010 11:47:17

20100505 - дата
11:47:18 - время
Виктория - пользователь
E - ?
Docs - Вид
DocPassed - Статус
2 - ?
O/551/24753 - ?

Мдя... Если выживите, используйте "Хранитель баз dbf"
http://infostart.ru/public/14958/

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

(16)
O/551/24753

O - документ
551 - вид документа
24753 - ид документа

Вот парсер mlg

1. Парсинг файла MLG (журнал регистрации 1С:Предприятие 7.7)
Книга знаний: Парсинг файла MLG (журнал регистрации 1С:Предприятие 7.7)

2. Внешняя обработка
http://infostart.ru/public/13996/

(16) Последнее - это ссылка. Её несложно преобразовать к нужному виду. Возьми за основу любую обработку, работающую с mlg - их довольно много. Лучше такую, которая использует ВК для корректного вычитывания с конца текстовых файлов большого объема.

(20) Хотя тебе не обязательно с конца... Можно и через ту же v7plus

(20) и (21) Да, на инфостарте их полно, некоторые используют v7plus

Всем спасибо, большое, буду разгребать.

(23) В части преобразования ссылки из вида mlg к виду хранения в базе. Если не найдешь - отпишись. Пороюсь в загашниках. Где-то валялись отлаженные процедуры с тех пор, когда пытались УРБД и МОД скрестить через лог... Только я ленивый, поэтому сначала всё-таки добросовестно поищи :)

еще один мой клиент :)

как всегда готов починить, почта в личке

SaverSetup делает бэкапы автоматом , поставил и забудь

(25) :)
И сколько уже благодарных клиентов?

(27) примерно 30-40 за полтора года, правда в основном случаи дешевые на час работы...

(28) Ну, тут жирный случай - шесть лет без бэкапов...

(24)  fisher, ну будь другом, посмотри пожалуйста, - я чет порылся ничего вразумительного пока не нашел, хотя, может уже голова соображать отказывается, на ДВ уже как 2 ч. ночи

(30) из mlg можно вытащить НЕ полный список ID и текстовое представление и описание действия, для востановления журнала - эта инфа почти бесполезна, так как в нее не попадают прогрмные действия, например программное удаление или создание.

(31) и еще совет, постарайся оценить время на востановление и ущерб от простоя, если время терпит - можно и покапатся самому, если нет - лучше заплатить :)

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

Хотя... 1986 год...

(30) Не нашел. Суть примерно такая:
Имеешь ссылку вида O/551/24753
О - тип объекта "Документ"
551 - вид объекта (по сути, номер таблицы DH)
24753 - ID документа в таблице, но в базе он хранится в 32-ричке.
Преобразовать можно с помощью недокументированной функции _IdToStr()

Кстати, ты уверен, что ВСЕ системные таблицы похерил? Есть еще парочка, откуда можно попытаться даты доков вытащить...

(31) Восстановить может и можно в каком то частном случае, а так нереально.

Смотри журнала документов нет
файла констант  нет ( истории реквизитов и констант нет )
файла ссылок нет ( нет отборов по общим реквизитам документов где включен отбор)
файла операций нет и особенно Ручные операции
Файла строк неограниченой длины нет

(33) Они скорее всего  через Windows copу делали судя по описанию из 6
а в архиве хранили только md и dd.

(35) я скорее всего возьмусь востановить (после анализа базы), по окончании дам список потерь которые наверняка будут, вот для списка потерь лог вполне подходит :)

(0) Если бухгалтерия белая т.е. база по какой сдавался баланс в налоговую то есть малый шанс восстановить ( и лучше позови специалиста )
а. Создаем чистую базу
б. Востанавливаем по sc все справочники.
в. Восстанавливаем все константы
г. на основании mlg ,sc, dh, dt востанавливаем документы непроведенные.
д. на основании первички перепроводим документы по квартально сверяя балансы.
Да написать легко сделать очень сложно.


Если в бух базе велся не  белый а иной учет то шансов вообще нет.

ps к 35
Даже не факт что план счетов есть ведь счета между этими двумя базами могли чуть чуть отличаться.

если конфа на опер учете то амба
если конфа написана на бух компоненте в гугл rainbow.dll
он же проект радуга, наверное давно заброшен

(41) брехня, на оперучете еще быстрее восстановить.

(41) Зачем на столько устаревшую вещь советуешь? Почему не 1С++?

(43) просто на проклубе еще с 2000-ых годов валяется поделка восстановления журнальчика на её основе, с тех пор её никто не переделывал видать..
:)