Сигнатура не равна 1cdbmsv8

Сигнатура не равна 1cdbmsv8

Именно 13-го июня в первый рабочий день база и слетела. Прямо с утра. При запуске пишет: «Файл базы данных поврежден. 1cv8.1CD» и все тут. Ни в конфигуратор ни в предприятие не пускает.

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

В общем вот исходные данные:

2. убитый файл 1Сv8.1CD весом 900 МБ датой от 12.06.2012;

3. рабочий файл 1Сv8.1CD весом 900 МБ датой от 26.04.2012;

На уровне подсознания понятно что из этого что то можно получить но пока не ясно как.

СЛАВА ИНТЕРНЕТУ. ИНФОРМАЦИЯ — вот в чем его сила. И пока, но все меньше, свободная (лирическое отступление).

По сути вопроса в Сети достаточно много информации, но все в итоге сводится к махинациям с копированием части исправного файла в убитый. Главный инструмент в данном случае — программка tool_1CD. Огромное спасибо ее автору Валерию (awa)!. Так же очень полезна статья того же автора: Краткое описание формата файлов *.1CD (файловых баз 1Сv8) . Ее пожалуй нужно прочитать перед началом попытки восстановления, тогда понятнее станет что и как делать.

ИТАК:

Первым делом конечно нужно скопировать оба файла (убитый и целый) куда нибудь подальше чтобы не потерять их исходники. Там мы их не трогаем. Затем скопировать их еще раз в папку где будем проводить эксперименты. Вот тут пожалуйста — издеваемся над ними как хотим ).

Еще до поиска в Сети пришла в голову мысль воспользоваться стандартной утилитой 1С CHDBFL.EXE для проверки и исправления файла базы.

После исправления этой утилитой 1С при загрузке стала ругаться на отсутствие таблицы _SYSTEMSETTINGS и кроме того размер файла базы сократился в 2 раза до 450 МБ. Очень странные результаты — хотя по отзывам данная утиль довольно грубая и помогает далеко не всегда, а иногда и усугубляет ситуацию (.

Ладно, заменяем жертву эксперимента файлом из «резервного хранилища».

Теперь читаем статью по формату 1Cv8.1CD и проникаемся. Ага, теперь более-менее понятно для чего и как можно использовать программу tool_1CD. Запускаем 2 экземпляра:

1.с убитым файлом:

2. с целым файлом:

Блин, ну сразу видно что 4-х таблиц не хватает. Каких -легко определить ибо порядок размещения одинаков. Таким образом у меня порушились:

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

Ну вот теперь мы знаем что файл 1Cv8.1CD структурирован и хранит в себе описание и содержимое всех таблиц, а в начале файла есть основная секция где указано размещение этих таблиц.

Тут нам без HEX-редактора не обойтись. А сейчас что-то мало бесплатных то ((((. А у меня еще с давних темных времен припасена коллекция редакторов и дебаггеров. Уж и не помню для чего)))).

Ну все — запускаем HEX-Assistant и снова открываем в нем оба наших подопытных файла:

Для тех, кто внимательно прочитал статью не секрет, что блок, где хранится размещение таблиц №2 и найти его можно по смещению 0х4000:

Вот она, вот она рыба моей мечты . . В tool_1CD таблицы расположены в том же порядке что и в файле пэтому мы легко находим смещения для недостающих у наc таблиц:

Так же видим что смещения одинаковы в обоих файлах. Это значит, что все вообще просто:

1. идем по указанному смещению в целом файле;

2. выделяем полностью фрагмент кода с начального смещения данной таблицы до начального смещения следующей;

3. копируем с заменой в убитый файл точно на те же адреса.

4. сохраняем изменения в бывшем убитом файле.

5. проверяем tool_1CD что таблицы появились. Прога ругаться может на индексы, но они после восстановятся.

Читайте также:  Зарегистрироваться в контакте бесплатно и быстро

6. (по своему усмотрению) прогоняем утилитой CHDBFL.EXE (она там поругается немного, можно не обращать внимания).

запускаем конфигуратор — тестирование и исправление

Я на всякий случай сделал все .

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

Так вот, прихожу на обед, а Наташа сидит с явным выражением шока на лице. У Наташи случился "Не удалось найти файл v8srvr ://dbeng8/f0577CFD0/Config/version.new" на рабочей базе бухгалтерии одной огромной организации. Резервным копиям десять дней, десять кровавых рабочих дней с шести утра до полуночи, и каждый утраченный в рабочей базе документик словно вырванный зуб.

В Интернетах по запросу "В моём 1C случилась беда" вываливается полтора форума, где вместо решений проблемы все пишут "У меня также. Помогите мне тоже. " Вот здесь, например.

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

Так вот, в чём проблема:
1C 8.2 может быть построен на базе SQL сервера (мне было бы проще, в таком случае) или на базе файловой системы (и у нас именно такой случай). Вот в этом втором случае вся конфигурация и данные хранятся в огромном файле с расширением 1CD, и что там внутри с первого раза не очень понятно.
И сегодня выяснилось, что этот огромный файл не хочет работать.

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

Встроенная утилита chdbfl , которая идёт с 1C, сообщила мне, что данные как-то очень уж безвозвратно попортились, и она не готова мне помочь. Ну ладно, мы и не думали, что будет просто.

Далее в интернете я обнаружил чудную программу Tool_1CD. Она открывает этот самый большой побитый файл и читает всё, что в нём скрыто. Утилита прочитала базу без проблем, с помощью неё я сразу же сохранил конфигурацию в формате cf на всякий случай. Ну и вот, он, этот самый негодяйский файл version.new.

Видим, что с файлом всё в порядке, он себя хорошо чувствует.
Судя по всему, вся проблема в том, что этого файла быть там не должно. Вот смотрим этой же утилитой живую конфигурацию:

Действительно, у нормальных ребят таких файлов нет. У нормальных ребят файл versions не имеет никакого расширения.

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

Вам наверное не очень понятно, почему я называю versions файлом, и как так может быть, что в файле конфигурационной базы скрыты другие файлы. Да, мой юный друг, это вполне модная затея — хранить в одном файле массу других файлов. Вспомни архивы на своём компьютере, там именно так. Вот и база 1C представляет из себя кучу таблиц, и в ячейках этих таблиц между делом могут храниться целые файлы. Если твой 1C собран на базе SQL — там будет ровно такая же фигня, и благодаря открытости формата SQL ты можешь подключиться консолью БД и увидеть всё своими глазами.

Так вот, в таблице CONFIG у нас обнаружились непонятные файлы, и судя по всему проблема в них. Разглядывание глазами привело меня к мысли, что в этой таблице находится конфигурация базы данных. А сами документы находятся где-то в другой таблице. Наташа поклялась мне, что с момента резервной копии она не очень существенно меняла конфигурацию, и структура данных не поменялась.

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

Читайте также:  Майкрософт уан драйв что это такое

Вот здесь автор программы Tool_1CD благородно раскрыл примерный формат файла 1CD. Это очень помогло. Спасибо тебе, автор программы Tool_1CD. И программа хорошая, и формат файла мне пригодился.

Для того, чтобы комфортно ковыряться в бинарных файлах, мужчине нужно иметь в доме шестнадцатиричный редактор. Я не пользовался ничем подобным уже лет семь. Стал скачивать с интернета эти самые редакторы: Ultraedit, Hiew, 010 Editor — а они все платные! Представляете, в яндексе уже стало проблематичным найти нормальную взломанную версию шестнадцатиричного редактора, куда катится этот мир?
В итоге поставил HxD, он сделал всю грязную работу.

Вот люди на форуме пишут свои рецепты:

4. Собираем TotalCommander-ом, сохраняем, даже если будет жаловатся(на crc).

А потом другие люди это пробуют сделать и пишут вот такие комментарии:
Но открыв в редакторе файл 1CD и сделав поиск по названию таблицы, я ничего не нашел. Больше ничего в голову не идет, поэтому решил спросить вашего совета.

Сроки горят бухгалтер в истерике. Пробовала по вашим советам скачать программу Tool_1CD, скачала. открыла. посмотрела. поня ла что ничего не поняла. Одна надежда на сдешних чудотворцев.

Подскажите, пожалуйста, уважаемые — КАК КОРРЕКТНО заменить таблицу CONFIG в битом 1CD? WinHEX’а не боюсь, со смещениями и прочим вроде разбираюсь — но что-то постоянно ускальзывает в этой задаче от меня. Поможете?

1. открывал winhex’ом мертвый 1CD, открывал живой параллельно (из типовухи или старого архива)
2. находил сегмент начала таблицы CONFIG (0x00009000) в обоих файлах
3. находил окончание таблицы (проще всего по началу CONFIGSAVE) в обоих файлах
4. копировал из нормального файла в битый (заменяя битое на нормальное). но видимо что-то не учитываю постоянно — формат файла корежится. и даже chdbfl.exe ругается на битость

Ну да, там всё оказалось не совсем тривиально.

Дальше статья будет совсем скучной, если вы не собираетесь прямо сейчас восстанавливать какой-нибудь 1CD файл, то можете не читать 🙂

Итак, открываем HxD и начинаем смотреть. Юзернейм awa сообщает, что правильный файл базы будет по размеру кратен 4096 байтам (в шестнадцатеричном — 0x1000) и размер базы указан в самом начале файла. Вот как хранится размер:

А вот так мы можем посмотреть, сколько на самом деле занимает файл:

Видим, что никакого обмана: размер файла 1FA31000, судя по тому, что в конце числа у нас три нуля, оно действительно кратно 0x1000. Ну, и в заголовке файла мы видим 31 FA 01 00 — если прочитать в другую сторону, получается 1FA31. Размер указан в блоках по 0x1000 байт — добавляем три нуля и получаем нужное значение.
Кстати, запомните этот трюк про шестнадцатеричное умножение на 0x1000. Просто дописываешь три нуля в конце и получаешь нужное число. Пригодится в жизни.

Дальше смотрим. Нам нужно найти таблицу CONFIG. Если просто открыть файл текстовым редактором и сделать поиск, то фраза не находится. Почему? Потому что в файле все строки хранятся в UNICODE и поэтому выглядят вот так:

Поэтому, если вы пользуетесь просмотрщиком из Total Commandera, переключите кодировку в Юникод и он вам всё найдет.
Ребята на форуме оказались правы. База Config действительно начинается на смещении 0x9000
Полнотекстовым поиском я также нашёл базу ConfigSave.

Оно оказалось на смещении 0C782000
Проанализировав целую базу, я увидел, что в ней таблица Config ожидаемо находится на 9000, а вот ConfigSave — на 07С83000. То есть, в старой базе блок Config длиннее аж на 0x1000 байт.
Ну, это сразу и навело меня на размышления. Наверняка если я вставлю в новую базу более длинный кусок, всё там посдвигается и 1C сойдет с ума.
Попробовал: удалил все байты с 0x9000 по 0x0C782000 и потом вставил из целой базы. Сохранил, запустил — стало ещё хуже: 1С говорит что база ему совсем не нравится, chdbfl сообщил, что данным пришёл конец, а Tool_1CD выдал кучу ошибок. И в этих ошибках написано: неправильное смещение блока C77F. И таблица Config открывается. Это означает, что пересадка таблицы Config прошла успешно, но вот всё остальное сломалось. Переходим к блоку C77F (0x0c77f000) — и там действительно нет начала блока. А в документации по 1CD мы выяснили, как должен выглядеть правильный блок. Вот так:

Читайте также:  Как выбрать браузер по умолчанию андроид

Ну, значит, действительно — все данные в файле сместились и это нарушает целостность данных.
Продолжаем разбираться, и читаем у awa про корневой объект. Оказывается, внутри файла 1CD есть блок, в котором хранятся смещения всех таблиц. Соответственно, смещение таблицы Config не меняется и поэтому она открывается утилитой верно, а все остальное съезжает. И нужно что-то с этим делать. Я нашёл этот корневой объект на смещении 0x4000 :

Вот полюбуйтесь, как выглядит этот корневой объект на целой и сломанной базе. Начинается он с текста ru_RU, затем ниже мы видим значения 00 00 05 CD (всё хранится в обратную сторону, не забыли?) — эти значения одинаковые в обоих файлах — количество таблиц. Дальше идёт ещё одна одинаковая запись 00 00 00 05. Так вот, это и есть начало блока таблицы Config — 5000, а не 9000. Я сравнил отрезки с 5000 до 9000 в двух файлах (старом и новом) и там есть какая-то разница, в которую я не стал вникать. Поэтому я пришёл к мысли, что и копировать блок Config надо не с того места, где в файле написано слово Config, а именно со смещения 0x5000.
Далее в корневом объекте мы видим записи 00 00 C7 7E и 00 00 С7 7F — это как раз начало блока ConfigSave. Видите — отличаются ровно на 1000, но тоже не указывают ровно на то место, где находится слово ConfigSave.

Теоретически, усидчивый парень может запихнуть из рабочей базы в нерабочую блок Config, а затем поправить все смещения. Но я поленился так делать. Я решил попробовать каким-то образом сравнять размеры блоков Config, чтобы ничего не сдвигалось. И вот что я сделал:
1. Я скопировал старый Config в разбитую базу.
2. В корневом объекте исправил 00 00 C7 7E на 00 00 C7 7F потому что блок Config стал длиннее и следующая таблица сдвинулась.
3. Перешёл на 00 00 C7 7F и стал смотреть:

Вот у нас начало блока и далее — адрес смещения, где должна начинаться таблица. Перехожу к этому смещению (C782000) и там буквально экраном ниже начинается таблица ConfigSave. Но между текущим блоком и следующим методом прокручивания обнаруживается какой-то непонятный пустой блок:

И в этот момент я подумал: в таблице ConfigSave хранится промежуточная конфигурация. Наверное, ничего страшного не произойдет, если она будет не совсем целая.
Поэтому я совершенно не переживая взял и удалил целый блок с 0C780000, ровно 0x1000 байт — до следующего блока.
Всё сдвинулось обратно, и смещения стали совпадать с тем, что указано в корневом объекте.

Ну, тогда я это сохранил и запустил 1C. Я был абсолютно уверен, что все заработает и оно заработало.
Из конфигуратора я тут же сделал резервные копии данных.
Затем я на всякий случай проверил базу через chdbfl, она ругнулась на таблицу ConfigSave, но сообщила, что всё починено.

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

Ссылка на основную публикацию
Самый дорогой самсунг 2018
Samsung / Самсунг - южнокорейская компания, ведущий производитель смартфонов в мире. В первом квартале 2018 года доля Самсунг на мировом...
Регистрбухгалтерии хозрасчетный остатки параметры
В 1С:Предприятии 8 для отражения движения различных ресурсов, денежных средств и иных материальных ценностей существует регистр бухгалтерии. Регистр бухгалтерии предназначен...
Регистрация смарт тв филипс
На протяжении многих лет компания Philips остаётся одним из крупнейших производителей телевизоров в мире. Сегодня она занимает третье место после...
Самый лучший smart tv
Ежегодные обновления телевизионных технологий делают телевизоры уже больше, чем обычным экраном для демонстрации каналов. Растет популярность функции Smart TV, которая...
Adblock detector