Здравствуйте. Следующая проблема:
База данных 1С, запускается без ошибок, но при входе в список документов Реализации вылетает с ошибкой, в тексте которой особо ничего полезного не дано.
Тестирование из конфигуратора дает такую же ошибку. Тестирование chdbfl.exe дает это (без галочки "исправлять"):
Повреждена таблица размещения внутреннего файла <Данные таблицы '_DOCUMENT233'>
Повреждена таблица размещения внутреннего файла <Данные неограниченной длины таблицы '_COMMONSETTINGS'>
Повреждены данные таблицы '_DOCUMENT254'
И это (с галочкой "исправлять"):
Повреждена таблица размещения внутреннего файла <Данные таблицы '_DOCUMENT233'>
Повреждена таблица размещения внутреннего файла <Данные неограниченной длины таблицы '_COMMONSETTINGS'>
Повреждены данные таблицы '_DOCUMENT233'. Восстановлено 3317 из 3466 записей.
Повреждены данные таблицы '_DOCUMENT254'. Восстановлено 3470 из 3471 записей.
После этого база прекрасно работает, но в ней исчезает около сотни документов Реализации.
В Tool1CD в таблице _DOCUMENT254 (это счет-фактуры выданные) последние две записи кривые, с непонятными данными. В таблице _DOCUMENT233 Тоже последние записи кривые, при этом все усложняется тем, что они не хотят нормально читаться: выходит сообщение "Попытка чтения блока за пределами файла". При этом адрес смещения у этих последних строк вообще какой-то непонятный. Такого нет, если смотреть через HEX-редактор.
Возникают следующие гипотезы:
1. Нужно удалить некорректные строки в таблицах
2. Возможно, в заголовке таблицы Реализации указан не верный размер самой таблицы с данными. Возможно, нужно его поправить.
Но вопрос как редактировать БД? Tool1CD и прочие инструменты не работают с базой, так как она в формате 8.3.8. Конвертировать ее не получается - она выдает ошибку. Остается только HEX, но я совершенно не знаю как в нем искать эти самые строки. Понимаю, что где-то есть таблица размещения, где должны быть адреса, но я не смог ее найти.
Опыта в восстановлении у меня совершенно нет, но я честно двое суток нон-стоп пытался разобраться самостоятельно, но, кажется, придется прибегнуть к помощи сообщества.
База данных 1С, запускается без ошибок, но при входе в список документов Реализации вылетает с ошибкой, в тексте которой особо ничего полезного не дано.
Тестирование из конфигуратора дает такую же ошибку. Тестирование chdbfl.exe дает это (без галочки "исправлять"):
Повреждена таблица размещения внутреннего файла <Данные таблицы '_DOCUMENT233'>
Повреждена таблица размещения внутреннего файла <Данные неограниченной длины таблицы '_COMMONSETTINGS'>
Повреждены данные таблицы '_DOCUMENT254'
И это (с галочкой "исправлять"):
Повреждена таблица размещения внутреннего файла <Данные таблицы '_DOCUMENT233'>
Повреждена таблица размещения внутреннего файла <Данные неограниченной длины таблицы '_COMMONSETTINGS'>
Повреждены данные таблицы '_DOCUMENT233'. Восстановлено 3317 из 3466 записей.
Повреждены данные таблицы '_DOCUMENT254'. Восстановлено 3470 из 3471 записей.
После этого база прекрасно работает, но в ней исчезает около сотни документов Реализации.
В Tool1CD в таблице _DOCUMENT254 (это счет-фактуры выданные) последние две записи кривые, с непонятными данными. В таблице _DOCUMENT233 Тоже последние записи кривые, при этом все усложняется тем, что они не хотят нормально читаться: выходит сообщение "Попытка чтения блока за пределами файла". При этом адрес смещения у этих последних строк вообще какой-то непонятный. Такого нет, если смотреть через HEX-редактор.
Возникают следующие гипотезы:
1. Нужно удалить некорректные строки в таблицах
2. Возможно, в заголовке таблицы Реализации указан не верный размер самой таблицы с данными. Возможно, нужно его поправить.
Но вопрос как редактировать БД? Tool1CD и прочие инструменты не работают с базой, так как она в формате 8.3.8. Конвертировать ее не получается - она выдает ошибку. Остается только HEX, но я совершенно не знаю как в нем искать эти самые строки. Понимаю, что где-то есть таблица размещения, где должны быть адреса, но я не смог ее найти.
Опыта в восстановлении у меня совершенно нет, но я честно двое суток нон-стоп пытался разобраться самостоятельно, но, кажется, придется прибегнуть к помощи сообщества.
По теме из базы знаний
- Стратегия резервного копирования базы данных для MS SQL Server
- Восстановление файловой версии базы данных *.1CD после ошибки динамического обновления.
- Восстановление работоспособности файловой базы. 0. Введение
- Файловые базы *.1CD. Физическая структура. Восстановление.
- Восстановление файловой базы с помощью tools 1cd
Найденные решения
Проблему удалось решить !!
Проблема была в том , что слетел номер страницы таблицы размещения Данная таблица описывалась полной структурой размещения () . Таблица данных имела 2 массив страниц. Ссылка на первый массив была корректной , а вот на второй была неверна и указывала на пустые записи .
Поэтому пришлось искать записи данной таблицы (наверное это самое сложное в данной задачи ) , по найденной записи получать номер блока этой записи и искать номер этого блока в каких таблицах размещения он участвует (а должен он участвовать только в одной таблице размещения) и уже этот адрес указывать как правильный адрес на массив страниц.
В результате при прогонке через chdbfl теперь теряется только одна запись
Проблема была в том , что слетел номер страницы таблицы размещения Данная таблица описывалась полной структурой размещения () . Таблица данных имела 2 массив страниц. Ссылка на первый массив была корректной , а вот на второй была неверна и указывала на пустые записи .
Поэтому пришлось искать записи данной таблицы (наверное это самое сложное в данной задачи ) , по найденной записи получать номер блока этой записи и искать номер этого блока в каких таблицах размещения он участвует (а должен он участвовать только в одной таблице размещения) и уже этот адрес указывать как правильный адрес на массив страниц.
В результате при прогонке через chdbfl теперь теряется только одна запись
Прикрепленные файлы:
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(15)
1) сделайте 2 копии вашей базы
2) одну из копий прогоните через chdbfl с исправлением
3) откройте 2 файла в HEX и сравните что поменялось (там есть функция сравнить файлы )
после этого надо попытаться выяснить где идет косяк
Еще вариант можно попробовать перейти по смещению последней нормальной записи и посмотреть что идет после этой записи (если мы знаем размер одной записи можно вычислить начало и конец следующих записей)
1) сделайте 2 копии вашей базы
2) одну из копий прогоните через chdbfl с исправлением
3) откройте 2 файла в HEX и сравните что поменялось (там есть функция сравнить файлы )
после этого надо попытаться выяснить где идет косяк
Еще вариант можно попробовать перейти по смещению последней нормальной записи и посмотреть что идет после этой записи (если мы знаем размер одной записи можно вычислить начало и конец следующих записей)
(16)
(16)
Так тоже пробовал. Но разве следующая запись в файле идет сразу после предыдущей? Они ведь могут быть вообще разбросаны по базе.
после этого надо попытаться выяснить где идет косяк
Да, спасибо, я так уже пробовал. Разница в файлах огромная. Там, видимо, происходит реиндексация и все очень сильно разнится.
(16)
Еще вариант можно попробовать перейти по смещению последней нормальной записи
Так тоже пробовал. Но разве следующая запись в файле идет сразу после предыдущей? Они ведь могут быть вообще разбросаны по базе.
(21) в описании tools 1cd смотрим размер записи в данном примере она равняется 185 - переводим в 16- ричную систему получаем B9 (см . описание таблицы)
чтобы получить начало послед. . записи прибавим B9 к смещению к предпоследней - можешь проверить ))) AE01ABF6 + B9 = AE01ACAF (см. расчет записи)
столбец file offset в tools 1cd отсортирован по возрастанию
чтобы получить начало послед. . записи прибавим B9 к смещению к предпоследней - можешь проверить ))) AE01ABF6 + B9 = AE01ACAF (см. расчет записи)
столбец file offset в tools 1cd отсортирован по возрастанию
Прикрепленные файлы:
(24) Есть еще один лайф хак , правда не знаю будет ли он работоспособный в вашем случае
Tools 1cd для 8.3.8 не совсем не работоспособный ,выбрать нужную таблицу и через меню файл можно выгрузить файлы с данными (decr, data,index,blob) и открыть в Hex так вы получить все записи таблицы с данными , по которым можно искать в основной базе
Tools 1cd для 8.3.8 не совсем не работоспособный ,выбрать нужную таблицу и через меню файл можно выгрузить файлы с данными (decr, data,index,blob) и открыть в Hex так вы получить все записи таблицы с данными , по которым можно искать в основной базе
Прикрепленные файлы:
НЕХ редактором мне кажется нереально найти битые строки.
Если сделать тестирование и исправление стандартными средствами то думаю он просто почистит таблицы базы.
Хотя как вариант можно попробовать это сделать, вдруг он битые ссылки на документы почистит
Если сделать тестирование и исправление стандартными средствами то думаю он просто почистит таблицы базы.
Хотя как вариант можно попробовать это сделать, вдруг он битые ссылки на документы почистит
Проблему удалось решить !!
Проблема была в том , что слетел номер страницы таблицы размещения Данная таблица описывалась полной структурой размещения () . Таблица данных имела 2 массив страниц. Ссылка на первый массив была корректной , а вот на второй была неверна и указывала на пустые записи .
Поэтому пришлось искать записи данной таблицы (наверное это самое сложное в данной задачи ) , по найденной записи получать номер блока этой записи и искать номер этого блока в каких таблицах размещения он участвует (а должен он участвовать только в одной таблице размещения) и уже этот адрес указывать как правильный адрес на массив страниц.
В результате при прогонке через chdbfl теперь теряется только одна запись
Проблема была в том , что слетел номер страницы таблицы размещения Данная таблица описывалась полной структурой размещения () . Таблица данных имела 2 массив страниц. Ссылка на первый массив была корректной , а вот на второй была неверна и указывала на пустые записи .
Поэтому пришлось искать записи данной таблицы (наверное это самое сложное в данной задачи ) , по найденной записи получать номер блока этой записи и искать номер этого блока в каких таблицах размещения он участвует (а должен он участвовать только в одной таблице размещения) и уже этот адрес указывать как правильный адрес на массив страниц.
В результате при прогонке через chdbfl теперь теряется только одна запись
Прикрепленные файлы:
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот