Добрый день уважаемые форумчане.
прошу помощи у гуру. !!!
Проблема с востановлением базы - перестала запускаться база.
Конфигурация БП 3.0.64.54 Базовая - Знаю точно.
cnvdbfl И ТИИ не нужно предлагать уже все перепробовал в разных вариантах не помогает,
Поможет только Tool_1CD или Хэш редактор.
Резервных копий нет ... ранее базу вел не я ... я понимаю всю прелесь бекапов ...
Формат Базы данных 8.3 при конвертации
cnvdbfl.exe -c -f 8.2.14 "C:\Base\!!! Base_TEST\1Cv8.1CD"
выходит ошибка База данных повреждена ...
То есть для того чтобы воспользоваться Tool_1CD и перегрузить таблицы CONFIG и CONFIGSAVE из нормально рабочей БП 3.0.64.54 Базовой мне пришлось восопльзоваться cnvdbfl при этом были такие ошибки
Повреждена таблица размещения внутреннего файла <Данные неограниченной длины таблицы 'CONFIG'>
Повреждена таблица размещения внутреннего файла <Данные таблицы '_REFERENCE94'>
Повреждена таблица размещения внутреннего файла <Данные таблицы '_INFORG29058'>
Повреждена таблица размещения внутреннего файла <Данные таблицы '_REFERENCE75'>
Повреждены данные таблицы '_INFORG12288'. Восстановлено 2092 из 2110 записей.
Повреждены данные таблицы '_INFORG18300'. Восстановлено 3 из 3 записей.. Потеряно 1 значений полей неограниченной длины
Повреждены данные таблицы 'CONFIG'. Восстановлено 28875 из 41282 записей.
Повреждены данные таблицы 'PARAMS'. Восстановлено 0 из 29 записей.
Повреждены данные таблицы 'FILES'. Восстановлено 0 из 15 записей.
и тд - еще много чего ...
Затем удалось переконвертировать формат БД на 8.2.14 и загрузить таблицы CONFIG и CONFIGSAVE из Нормальной базы.
Но при этом при открытии Конфигуратора - Ошибка формата потока.
если ли какой способ переконвертировать базу в формат 8.2.14 не исопльзуюя cnvdbfl ТИИ ???
Или есть какой способ загрузить поврежденную Файловую базу на SQL ???
В общем сам не знаю как дальше быть ... Как востановить базу на ваш взгляд ???
- вот ссылка на поврежденный файл - https://cloud.mail.ru/public/42py/r9J5KHSnK - если будет возможность пожалуйста посмотрите.
(1) Итак , текущую базу не поднять , DBSHEMA - потеряна, записи таблицы PARAMS тоже потеряны, конвертации в 8.2.14 происходит с ошибками , поэтому единственный вариант который я вижу - это ручной перенос таблиц в чистую базу с помощью утилиты Tools_1CD без конвертации поврежденной базы, Вариант конечно не надежный, и трудоемкий, но стоит попробовать и состоит он в следующем:
1) Создать чистую базу нужного релиза и сконвентировать его в формат 8.2.14 - открыть в tools_1cd (Tools_1cd для редактирования)
2) Открыть поврежденную базу в другой Tools_1cd читающий формат 8.3.8 но без возможности редактирования ( файл приложу ниже)
3) Пробежаться по всем таблицам поврежденной базы и посмотреть в каких из них есть данные (можно конечно смотреть не все а например только справочники, документы , регистры накопления и регистры сведений тут надо смотреть ) , желательно каждую такую таблицу куда-нибудь выписать например в Excel так же необходимо для каждой такой таблицы указать длину записи (см раздел описание )
4) Теперь самое сложное - найти соответствующую таблицу для каждой из выписанных таблиц в чистой базе. открываем tools_1сd с чистой базой , бежим по списку таблиц и ищем таблицу по длине записи - Например в Вашей базе есть таблица ACCUMRG15433 которая содержит какие-то данные , длина записи 239 а в чистой базе ее соответствует таблица ACCUMRG27021 с такой же длинной записи (см скрин)
5) Из новой базы экспортируем нужную таблицу куда-нибудь на диск создаться папка c именем экспортируемой таблицы с 3-5 файлами внутри (descr, data, index,blob,root)
6) Возвращаемся в tools_1cd с поврежденной базой выбираем нужную таблицу далее идем меню файл-Сохранить и выбираем 1 из 3 пунктов
Сохранить файл Records Таблицы - соответствует файлу data
Сохранить файл Blob Таблицы - соответствует файлу Blob
Сохранить файл index Таблицы - соответствует файлу index
т.е. выбрали пункт B]Сохранить файл Records Таблицы[/B] и этот файл сохраняем в папку из п.5 перезаписывая файл data и так для каждого пункта
7) Возвращаемся в tools_1cd с чистой базой и импортируем таблицу обратно уже с обновленными данными
И так повторить для каждой из таблиц с данными из поврежденной базы
Самое сложное здесь это поиск соответствия таблиц между новой и поврежденной базой и поле длина записи для таблиц одного и того же типа таблиц не уникальна , но другого выхода как сопоставить таблицы я не вижу.
(2) Я бы не был бы так категоричен , первая проблема которую я увидел это повреждены файлы описания таблиц , из-за этого происходит смещение записей, если это исправить через hex , то возможно база будет открываться , в крайнем случае может сконвертится без ошибок
первая проблема которую я увидел это повреждены файлы описания таблиц
Описание таблиц, безусловно, важно. Но не менее (а по-моему, даже более) важно - содержимое таблиц.
Собственно, именно содержимым каждая база отличается от всех прочих.
А тут я вижу, что начиная со смещения 2B200000h и до конца файла (44% всего объема базы) - сплошные нули. И что вы надеетесь получить в исправленных таблицах после конвертации?
(4) Не факт что в базе много данных , если просматривать с помощью tools_1cd читающий формат 8.3.8 есть какие то данные в справочниках и регистрах сведений и немного документов , с учетом этого можно предположить что 40 % базы может быть пустым, плюс размер страницы 8К , поэтому может создаться ощущения что база пустая, поэтому я вижу смысл хотя бы попытаться восстановить таблицы описания (хотя это будет сложно используя только hex редактор)
(5) при таких объемных повреждениях - "восстановление" адресов таблиц никогда не помогало.
Максимум, что работает при восстановлении таблиц - это восстановление CONFIG.
(7) Я не могу сказать что у меня большой опыт по восстановлению таблиц , но все же что-то умею , восстановление CONFIG - это не панацея а всего лишь самый простой способ попробовать исправить ситуацию и по моей статистики в 70 % случаев этого не достаточно , а в этом конкретном случае это точно не поможет ,про восстановление адресов таблиц - возможно - но из-за этого поехала другая информация например ссылки на блоки с данными
(1) Итак , текущую базу не поднять , DBSHEMA - потеряна, записи таблицы PARAMS тоже потеряны, конвертации в 8.2.14 происходит с ошибками , поэтому единственный вариант который я вижу - это ручной перенос таблиц в чистую базу с помощью утилиты Tools_1CD без конвертации поврежденной базы, Вариант конечно не надежный, и трудоемкий, но стоит попробовать и состоит он в следующем:
1) Создать чистую базу нужного релиза и сконвентировать его в формат 8.2.14 - открыть в tools_1cd (Tools_1cd для редактирования)
2) Открыть поврежденную базу в другой Tools_1cd читающий формат 8.3.8 но без возможности редактирования ( файл приложу ниже)
3) Пробежаться по всем таблицам поврежденной базы и посмотреть в каких из них есть данные (можно конечно смотреть не все а например только справочники, документы , регистры накопления и регистры сведений тут надо смотреть ) , желательно каждую такую таблицу куда-нибудь выписать например в Excel так же необходимо для каждой такой таблицы указать длину записи (см раздел описание )
4) Теперь самое сложное - найти соответствующую таблицу для каждой из выписанных таблиц в чистой базе. открываем tools_1сd с чистой базой , бежим по списку таблиц и ищем таблицу по длине записи - Например в Вашей базе есть таблица ACCUMRG15433 которая содержит какие-то данные , длина записи 239 а в чистой базе ее соответствует таблица ACCUMRG27021 с такой же длинной записи (см скрин)
5) Из новой базы экспортируем нужную таблицу куда-нибудь на диск создаться папка c именем экспортируемой таблицы с 3-5 файлами внутри (descr, data, index,blob,root)
6) Возвращаемся в tools_1cd с поврежденной базой выбираем нужную таблицу далее идем меню файл-Сохранить и выбираем 1 из 3 пунктов
Сохранить файл Records Таблицы - соответствует файлу data
Сохранить файл Blob Таблицы - соответствует файлу Blob
Сохранить файл index Таблицы - соответствует файлу index
т.е. выбрали пункт B]Сохранить файл Records Таблицы[/B] и этот файл сохраняем в папку из п.5 перезаписывая файл data и так для каждого пункта
7) Возвращаемся в tools_1cd с чистой базой и импортируем таблицу обратно уже с обновленными данными
И так повторить для каждой из таблиц с данными из поврежденной базы
Самое сложное здесь это поиск соответствия таблиц между новой и поврежденной базой и поле длина записи для таблиц одного и того же типа таблиц не уникальна , но другого выхода как сопоставить таблицы я не вижу.
А как вы таблицы друг от друга отделяете? А соответствия между ними? У документа - сразу отдельная таблица Шапка, и отдельная - ТЧ.
А в базе подобных связанных таблиц может быть сколько угодно.
(8) Немного не понял вопроса -
Не я отделяю - отделяет tools_1cd
_DOCUMENT353 - Основная таблица документов т.е. содержит ссылки на все документы определенного вида
_DOCUMENT353_VT10001 - одна из таблиц табличных частей документов из _DOCUMENT353
_DOCUMENT353_VT10014 - другая таблица таб.части документа
Соответственно при экспорте выгружаем все таблицы связанные с этим документом
В общем сегодня дошли руки самому проверить предложенный мною же способ.
Удалось перенести часть справочников и документов в рабочую базу , но так как в поврежденной базе пропали данные многих таблиц (например данные таблицы номенклатура) то в документах отражается "объект не найден" т.е. большая часть данных безвозвратно утеряна.(возможно при наличии старой копии можно было бы частично эти данные достать )
Небольшие замечание к способу
6) Возвращаемся в tools_1cd с поврежденной базой выбираем нужную таблицу далее идем меню файл-Сохранить и выбираем 1 из 3 пунктов
Сохранить файл Records Таблицы - соответствует файлу data
Сохранить файл Blob Таблицы - соответствует файлу Blob
Сохранить файл index Таблицы - соответствует файлу index
Как выяснилось - файл index переносить не нужно , так как при заходе в базу формата 8.2.14 возникает ошибка - размер файла index не кратен 0x1000 (причем возникла она только для таблиц справочников - для регистров накопления и документов проблем не возникало) , а при конвертации формат 8.3.8 возникает ошибка при конвертации.
Так же после переноса данных таким способом и заход в базу формата 8.2.14 данные в базе не отображаются , нужно произвести обратную конвертацию в формат 8.3.8
А для поиска таблиц с определенной длинной записи использовал компоненту 1cdLib
так как в поврежденной базе пропали данные многих таблиц (например данные таблицы номенклатура) то в документах отражается "объект не найден" т.е. большая часть данных безвозвратно утеряна.
Что и требовалось доказать, см. (4).
Разумеется, специалисту всегда полезно "потренироваться на кошках" (даже на дохлой кошке), но автору ветки этот опыт очень слабо поможет.
(12) согласен , вообще была надежда что могли быть полезные данные например контрагенты или номенклатура какие-то документы хоть немного но можно было бы спасти эти данные что бы заново не набивать
Случался у меня подобный казус. Лаборатория Восстановление данных на Беговой меня тогда спасла. Они легко восстанавливают потерянные данные, сама бы я точно ничего подобного не сделала. Цены,конечно не кусают, но срочное восстановление требует дополнительных расходов.