Длина файла базы не кратна длине блока 0х1000 что делать
1С 8.3 : Опыт восстановления файловой базы 1Cv8.1CD
Именно 13-го июня в первый рабочий день база и слетела. Прямо с утра. При запуске пишет: «Файл базы данных поврежден. 1cv8.1CD» и все тут. Ни в конфигуратор ни в предприятие не пускает.
Последний бэкап понятно как обычно старый, ибо при последнем обновлении 1С рабочую базу перенесли в другую папку, которая соответственно в архив не попадала.
В общем вот исходные данные:
2. убитый файл 1Сv8.1CD весом 900 МБ датой от 12.06.2012;
3. рабочий файл 1Сv8.1CD весом 900 МБ датой от 26.04.2012;
На уровне подсознания понятно что из этого что то можно получить но пока не ясно как.
ИТАК:
Еще до поиска в Сети пришла в голову мысль воспользоваться стандартной утилитой 1С CHDBFL.EXE для проверки и исправления файла базы.
Ладно, заменяем жертву эксперимента файлом из «резервного хранилища».
Теперь читаем статью по формату 1Cv8.1CD и проникаемся. Ага, теперь более-менее понятно для чего и как можно использовать программу tool_1CD. Запускаем 2 экземпляра:
Ну вот теперь мы знаем что файл 1Cv8.1CD структурирован и хранит в себе описание и содержимое всех таблиц, а в начале файла есть основная секция где указано размещение этих таблиц.
Тут нам без HEX-редактора не обойтись. А сейчас что-то мало бесплатных то ((((. А у меня еще с давних темных времен припасена коллекция редакторов и дебаггеров. Уж и не помню для чего)))).
Для тех, кто внимательно прочитал статью не секрет, что блок, где хранится размещение таблиц №2 и найти его можно по смещению 0х4000:
Так же видим что смещения одинаковы в обоих файлах. Это значит, что все вообще просто:
1. идем по указанному смещению в целом файле;
2. выделяем полностью фрагмент кода с начального смещения данной таблицы до начального смещения следующей;
3. копируем с заменой в убитый файл точно на те же адреса.
4. сохраняем изменения в бывшем убитом файле.
5. проверяем tool_1CD что таблицы появились. Прога ругаться может на индексы, но они после восстановятся.
6. (по своему усмотрению) прогоняем утилитой CHDBFL.EXE (она там поругается немного, можно не обращать внимания).
Все. Время принимать поздравления и обещания расцеловать от бухгалтерии и наставления от начальства по поводу необходимости ежедневного архивирования. В который раз ))))).
Длина файла базы не кратна длине блока 0х1000 что делать
Перед тем как начать исправлять базу обязательно сделайте резервную копию!
1. Через конфигуратор
Выбрать «тестирование и исправление» и запустить.
2. Утилита chdbfl.exe
Если в конфигуратор войти нет возможности можно воспользоваться утилитой chdbfl.exe. Ее скачивать не нужно, она находится в папке, где установлена 1С.
У меня утилита chdbfl.exe находится тут
Нужно ее запустить, выбрать файл 1Cv8.1CD в папке базы 1с, поставить галочку «Исправлять обнаруженные ошибки» и запустить.
3. Очистить кэш (более подробно смотреть тут) .
Бывают такие глюки\сбои которые очень хорошо исправляются очисткой кэша.
Например один пользователь входит в базу 1с и работает без проблем, а другой или войти не может или при входе у него куча ошибок и т.п.
Способ очень простой.
Нужно подключиться к компьютеру этого пользователя, запустить 1с чтобы появился список баз.
И сделать так:
1 Выбрать в списке нужную базу
2 Удалить ее из списка, сама база не удалится. Главное запомните или запишите где она лежит.
3 Заново ее пропишите.
Сейчас у одного из моих клиентов ситуация в которой не помог ни один из этих способов.
Клиент новый, поэтому я еще не до конца разобрался как у него все устроено.
База файловая, находится на вирт машине, 1с без сервера запускается с другой вирт. машины.
Возможно 1с просто не хватает ресурсов.
Базу скачал себе, запущу и попробую поработать в ней, если ошибка не появится, то проблема точно не в 1с, а в системном администрировании.
Тогда буду перенастраивать.
Узнал что ресурсов на компьютере клиента достаточно.
Решено. Проблема была в платформе.
Переустановка платформы и удаление старых версий полностью решило проблему. 🙂
Восстановление БД или «1С 8.х «Ошибка СУБД, файл базы данных поврежден»»
Чаще всего появление сообщения «Ошибка СУБД, файл базы данных поврежден 8.x» возникает именно при файловом режиме работы с конфигурацией (т.е. без использования сторонних СУБД).
Чаще всего появление сообщения «Ошибка СУБД, файл базы данных поврежден 8.x» возникает именно при файловом режиме работы с конфигурацией (т.е. без использования сторонних СУБД). Данный сбой происходит вследствие следующих причин:
1) Перебоев с электричеством в следствии чего происходит обрыв связи с сервером базы данных. Иначе говоря с компьютером где установлена БД 1С:предприятие 8.
2) Отключение или повисание локальной сети вследствие неправильной сетевой инфраструктуры предприятия, неправильно «обжатых» сетевых кабелей, порчей сетевого оборудования (хабов, свичей, роутреров, сетевых концентраторов).
3) Неправильного выхода и завершения работы системы 1С. Например: БД установлена на компьютере главного бухгалтера, по какой либо причине или в конце рабочего дня данный компьютер отключается при незавершенных сеансах 1С на других компьютерах; следствие – порча файла БД 1Cv8.CD
В большинстве случаев (скажем на 80%) данную ошибку можно исправить. Но сам факт ее возникновения уже негативно сказывается на внутренней структуре файла БД 1С и не гарантирует того что в дальнейшем данная ошибка не будет возникать или БД будет работать корректно. При частом возникновении данной ошибки следует задуматься об улучшении прежде всего сетевой структуры (локальной сети) предприятия.
Этапы исправления ошибки:
1) Создать резервную копию поврежденной базы данных. Это действие обязательно, т.к. существует риск что в результате процедуры исправления, база совсем перестанет работать. Это можно сделать двумя способами:
A. Можно сделать архив штатными средствами 1С:Предприятие через режим «Конфигуратор» БД. Но не всегда есть вероятность что можно зайти в конфигуратор. Т.к. при некоторых плачевных ситуациях в конфигуратор войти просто не состоится возможным.
Как сделать резервную копию базы данных 1С Вы можете прочитать в статье «Создание резервной копии 1С штатными седствами».
B. Можно просто скопировать папку с файлом БД в любой каталог жесткого диска компьютера, путь где находиться БД можно определить следующим образом (см. картинку ниже):
А) Для БД версий 8.1. она находится по следующему пути: «C:\Program Files\1cv81\bin«.
Б) Для БД версии 8.2. она находится по следующему пути: C:\Program Files\1cv82\ 8.2.18.61 \bin. Папка с цифрами есть версия установленной платформы конфигурации 8.2. Следует знать версию платформы на которой работает поврежденная БД 1С иначе утилита проверки выдаст ошибку о несоответствии версии файла БД.
Окно утилиты выглядит как на рисунке ниже:
Выберите нажав на кнопку 
файл базы данных 1Cv8.CD из каталога где находиться поврежденная БД. Полный путь к файлу пропишется в поле «Имя файла БД». Далее установите флажок «Исправлять обнаруженные ошибки» и нажмите кнопку «Выполнить».
Сразу же запуститься программа проверки, этот процесс может занять продолжительное время, начиная от нескольких минут до нескольких часов. Это зависит от размера базы данных, от скорости работы и мощности персонального компьютера на котором производится проверка. Чтобы ускорить эту операцию, база данных должна быть доступна локально (а не по сети), т.е. тестирование должно производиться на компьютере где установлена БД.
ОЧЕНЬ ВАЖНО: при проверки БД никто не должен заходить в проверяемую БД или же останавливать сеанс проверки.
Через некоторое время утилита завершит работу и выдаст сообщение о результатах тестирования исправления БД. Настоятельно рекомендуем выполнять проверку два раза, даже если результат проверки выдаст сообщение что никаких ошибок не обнаружено.
Если же после тестирования и исправления БД результат остался прежним: Вы не можете запустить БД 1С. То настоятельно рекомендуем создать новую БД путем восстановления из архивных копий.
Следует помнить, что восстановление данных, в том числе базы 1С не может быть гарантировано на 100%. Обязательно делайте резервные копии важной информации.
Что необходимо делать чтобы не пришлось прибегать к восстановлению физической целостности?
1) Регулярно создавать резервные копии БД 1С предприятие. Это можно делать или штатными методами сохранения данных 1С или же воспользовавшись специализированным программным обеспечение: например, системами резервного копирования Paragon Software.
2) Использовать терминальный режим доступа к базе данных 1С. Данный доступ во многом имеет свои плюсы. Например данные в этом случае не передаются по локальной сети от компьютера к компьютеру, передается только виртуальный рабочий стол через который происходит соединение с БД. Все нагрузка в этом случае распределяется на сервер, на котором установлена серверная операционная система. Соответственно, имея мощный источник бесперебойного питания на сервере, обрывы сети и выключение электричества никоим образом не влияют на работу БД 1С.
Краткое описание формата файлов *.1CD (файловых баз 1Сv8)
После того, как я выложил свою программку Tool_1CD ( http://infostart.ru/projects/3851/ ), оказалось, что интерес к формату файлов 1CD достаточно велик. Поэтому для всех желающих продолжить разбираться с форматом, или желающих написать свою программу, выкладываю свои текущие знания об этом формате.
Описание формата приведено в терминах языка C. Размер типа char – 1 байт, размер типа short int – 2 байта, размер типа int и unsigned int – 4 байта. Префиксом 0x обозначаются шестнадцатеричные числа.
Файлы баз *.1CD состоят из блоков длиной 4096 байт (0x1000). Соответственно, длина файла всегда кратна 4096.
Блок 0
char sig[8]; // сигнатура “1CDBMSV8”
unsigned int length;
Первые 8 байт – сигнатура базы «1CDBMSV8».
Следующие 4 байт – длина базы (файла) в блоках.
Предназначение поля unknown неизвестно, всегда содержит 1.
Объекты
Структура первого блока каждого объекта такова:
char sig[8]; // сигнатура “1CDBOBV8”
int length; // длина содержимого объекта
unsigned int version;
unsigned int blocks[1018];
Первые 8 байт – сигнатура базы «1CDBOBV8».
Есть 2 типа объектов.
Блок 1. Таблица свободных блоков
В blocks содержатся номера блоков, в которых собственно и находится содержимое таблицы свободных блоков. Значащими являются ненулевые значения в массиве blocks. Содержимое таблицы свободных блоков – это просто массив номеров свободных блоков:
unsigned int free_blocks[length];
Таким образом, в базе содержатся ровно length свободных блоков.
Когда системе требуется новый блок для данных, то она берет последний свободный блок из массива free_blocks и уменьшает length на 1. Если свободных блоков нет, то он создается в конце файла базы. Блоки, содержащиеся в массиве blocks, не являются свободными, а принадлежат объекту – таблице свободных блоков. В blocks может содержаться больше блоков, чем необходимо для хранения массива free_blocks.
Остальные объекты
В поле length содержится длина в байтах данных объекта.
В массиве blocks находятся индексы блоков, содержащих таблицу размещения данных объекта. Каждый блок, указанный в blocks, и являющийся частью таблицы размещения, имеет следующую структуру:
unsigned int datablocks[1023];
Повторим, в заголовочном блоке объекта находится массив blocks, содержащий индексы блоков с таблицей размещения. А в таблице размещения находятся блоки, содержащие сами данные.
Блок 2. Корневой объект
Для версии «8.1.0.0» структура выглядит так:
Т.е. различаются эти структуры только длиной поля lang. В поле lang содержится код языка базы. Код языка базы представляет собой строку в ANSI-кодировке. Мне встречались только базы с кодами «ru_RU» и «en». На что влияют эти коды языка, я не знаю, возможно, на порядок сортировки строк при построении индексов.
В поле numblocks содержится количество элементов в массиве tableblocks. В массиве же tableblocks содержатся индексы объектов, содержащих все таблицы данных. Т.е. таблиц в базе ровно numblocks.
Объект таблицы
Как видно из этого примера, здесь присутствуют имя таблицы (_Reference4), раздел описания полей таблицы (Fields), раздел описания индексов (Indexes), параметр Recordlock и раздел Files.
В разделе Files всегда содержатся три числа, которые содержат индексы заголовочных блоков объектов (по порядку) с записями таблицы, Blob-данными (строки неограниченной длины и двоичные данные) и индексами. Если какого-либо объекта у таблицы нет, то соответствующее число равно нулю.
В разделе Fields содержатся описания полей таблицы. Описание каждого поля содержит (по порядку): имя поля (FieldName), тип поля (FieldType), признак использования NULL (NullExists), длину (FieldLength), точность (FieldPrecision) и признак регистрочувствительности (FieldCaseSensitive).
Сколько байт занимает каждое поле в записи, и как его интерпретировать, зависит от параметров поля. Во-первых, если NullExists у поля равен 1, то первый байт поля является признаком NULL. Значение 0 этого байта означает, что поле не содержит значение (т.е. содержит NULL). В противном случае, поле содержит значение. Если же NullExists равен 0, то такого байта в поле нет.
Далее, размер и формат поля зависит от типа поля. Типы поля бывают такими:
Объект записей таблицы
Объект Blob таблицы
unsigned int nextblock;
Поле nextblock содержит индекс следующего блока, содержащего продолжение данных, или 0, если следующего блока нет. Поле length содержит длину данных в этом блоке (максимум 250). Поле data содержит сами данные. Нулевой блок всегда считается свободным, в поле nextblock он содержит индекс следующего свободного блока. Таким образом, с нулевого блока начинается цепочка свободных блоков.
В записях таблицы в полях с типом «NT» и «I» содержится индекс первого блока, с которого начинаются данные, относящиеся к этому полю данной записи.
Объект индексов таблицы
Редакция «Клерка» получила информацию от источников в ФНС о том, что в 2022 году налоговики начнут массово снимать расходы компаний.
Чтобы подготовить вас к непростому 2022 году, «Клерк» оперативно разработал уникальный курс по защите при налоговых проверках. Записаться и получить подарок тут.
Восстановление базы 1С Предприятие (DBF) после форматирования
Как выяснилось, резервная копия данной базы у клиента более, чем годовой давности.
Первый этап в решении подобных задач – это создание поблочной копии оригинального накопителя (или как принято писать со времен, когда носителями были только накопители на гибких и жестких магнитных дисках – посекторной). При вычитывании обнаруживается нестабильная скорость чтения, что говорит о серьезном износе NAND памяти (многократное чтение NAND контроллером страниц NAND памяти и коррекция ошибок за счет избыточности кодов коррекции ошибок (ECC ) весьма ресурсоемкая операции, что в итоге влияет на скорость чтения). При наличии непрочитанных участков необходимо заполнить их паттерном, который в дальнейшем нам поможет идентифицировать файлы, которые не были вычитаны целиком.
Далее приступаем к анализу. Необходимо установить, какая файловая система и в каких границах ранее была на USB flash. То есть, необходимо выполнить поиск регулярных выражений, характерных для различных метаданных файловых систем, но прежде, чем его начать, проверим простой вариант, который подразумевает, что границы разделов прежние. Для этого установим текущие параметры файловой системы.
рис. 2
В нашем случае видим по смещению 0x1C2 типа раздела 0x0B, означающее, что на данный момент на USB накопителе есть раздел FAT32, который начинается с 0x80 сектора (DWORD по смещению 0x1C6), длиной 0x003C2000 секторов (DWORD по смещению 0x1CA). Переходим к boot сектору описанного раздела в сектор 0x80 (в файле образа байтах 0x10000)
рис. 3
Необходимо вычислить начальную точку отсчета, то есть место нулевого кластера, относительно которого рассчитывается пространство, а также определить размер кластера.
Выполним проверку на предмет отсутствия записей в таблице размещения файлов и проведем процедуру сравнения копий на предмет разночтений.
Рис. 4
Сравнение копий FAT показало, что разночтения отсутствуют. Анализ содержимого одной из копий FAT показал, что согласно таблицы на разделе заполнен только один кластер.
Далее необходимо оценить корневой каталог на предмет удаленных записей. Позиция первого кластера корневого каталога указывается в boot сектор по смещению 0x2C=0x00000002. Для второго кластера в FAT указано FF FF FF 0F, что означает конец цепочки, то есть корневой каталог состоит из одного кластера.
рис. 5
По адресу, рассчитанному выше, мы видим корневую директорию (корневой каталог), в которой содержится единственная 32-байтная запись. По смещению 0x0B мы видим значение 0x08, которое указывает на тип записи – метка тома. Тот факт, что таблицы размещения файлов заполнены нулями, и в корневом каталоге нет намека на какие-либо иные записи, говорит о том, что данный раздел был отформатирован.
Для проверки предположения о том, что раздел не пересоздавался и все параметры файловой системы корректны, необходимо произвести поиск регулярного выражения 0x2E 0x2E 0x20 0x20 0x20 0x20 0x20 0x20 со смещением внутри сектора 0x20 (данное выражение признак начала директории FAT32).
рис. 6
При нахождении регулярного выражения необходимо удостовериться, что это действительно директория, по иным признакам, так как в некоторых случаях возможно совпадение и найденное регулярное выражение не является элементом директории. Согласно информации на рис. 6, можно сказать, что данная директория начиналась с 3 кластера (номер текущего кластера директории DWORD содержится в WORD по смещению 0x1A (младшая часть) и WORD по смещению 0x14 (старшая часть)) и описывалась в корневом каталоге, так как по смещениям 0x3A и 0x34 содержатся нули (начальный кластер родительской директории). Проверим, соответствует ли номер кластера данной директории нулевой точке отсчета файловой системы, созданной после форматирования. Для этого номер кластера директории умножим на размер текущего кластера и прибавим к нулевой точке 0x03*0x1000+0x40E000=0x411000. Как видим, расчетный адрес соответствует фактическому нахождению. Установить имя данной директории возможно только в случае, если ранее корневой каталог состоял более, чем из одного кластера, и ссылка на данную директорию была не в первом кластере, так как содержимое первого кластера при форматировании было полностью уничтожено вместе с таблицами размещения файлов.
Далее продолжим поиск регулярного выражения 0x2E 0x2E 0x20 0x20 0x20 0x20 0x20 0x20 со смещением внутри сектора 0x20.
рис. 7
Повторяем все проверки: 0x04*0x1000+0x40E000=0x412000. Снова видим соответствие положения директории параметрам текущей файловой системы. Но, кроме этого, видим, что есть номер кластера родительской директории 0x03, что говорит о том, что данная директория была вложенной, и взглянув на рис. 6, можно установить имя директории, которая изображена на рис. 7. Итак, согласно рис. 6, по смещению 0x4B видим значение 0x10 — это означает, что данная запись указывает на директорию, а по смещениям 0x5A и 0x54 число 0x00000004 – указатель на 4-й кластер. По смещению 0x40 – имя директории «BIN». Именно таким образом устанавливается взаимосвязь директорий в поврежденном FAT разделе. После выполнения еще некоторого числа проверок директорий в разных участках образа можно сделать окончательный вывод о том, что на данном накопителе состоялось форматирование в границах предшествующей файловой системы и параметры вновь созданной файловой системы унаследованы от предыдущей, то есть дальнейшие аналитические операции нужно проводить в рамках раздела, описанного в таблице разделов с учетом параметров текущей файловой системы.
Зная, что 1С база, состоящая из DBF файлов, должна содержать файл конфигурации 1CV7.MD, выполним поиск последовательности 0x31 0x43 0x56 0x37 0x20 0x20 0x20 0x20 0x4D 0x44. Для того, чтобы уменьшить количество заведомо ложных результатов, поиск лучше выполнять в рамках 32-байтных блоков с нулевым смещением.
Рис. 8
Таким образом, находим все директории, содержащие в себе указатель на файл 1CV7.MD. В нашем случае обнаружилась только одна такая директория, что позволяет предполагать, что мы нашли первый кластер необходимой директории. Далее следует анализ положения родительских директорий, вплоть до корневой директории. Каждая найденная директория прописывается в таблицу FAT (сначала как директория из одного кластера, посредством записи FF FF FF 0F для соответствующего элемента таблицы). Также в корневой директории прописывается ссылка на дочерний объект.
На текущем этапе мы выполним копирование найденных файлов с предположением об их непрерывности, так как обе копии FAT не содержат информации о фрагментации (напомним, что они были безвозвратно уничтожены системным администратором в результате необдуманного форматирования USB flash). После копирования директории 1С базы анализируем количество файлов. Учитывая, что фрагмент директории был размером в один кластер, то извлекли мы не более 126 файлов, что явно намного меньше, чем должно быть в директории с DBF и CDX файлами, относящимися к 1С базе. Примерно такой же результат выдадут программы автоматического восстановления, о чем свидетельствует результат, полученный системным администратором посредством использования R-Studio.
Среди извлеченных файлов есть 1CV7.MD (файл конфигурации) и 1СV7.DD (файл словаря данных). После выполнения проверки целостности создадим у себя на диске временную папку, куда поместим 1CV7.MD. Укажем данный путь при добавлении новой базы и откроем конфигуратор, посредством которого создадим чистую базу на основании этой конфигурации. Сравним сформированный DD файл с восстановленным, если описания и количество справочников идентичны, то никаких дополнительных действий не требуется, и, имея полный список файлов, можно приступать к поиску остальных фрагментов директории 1С базы. Для этого необходимо осуществить поиск последовательностей из ASCII кодов символов, используемых в именах недостающих DBF файлов. По мере обнаружения фрагментов директории дописывать в таблицу размещения файлов продолжение цепочки. После каждой операции дополнения цепочки директории выполнять копирование файлов и анализировать, насколько сократилась количество недостающих DBF файлов, и вновь формировать последовательность ASCII кодов символов для поиска следующего фрагмента.
рис. 9
Также необходимо помнить, что при записи цепочки фрагментов директории в таблицу размещения файлов, необходимо анализировать фрагменты, чтобы стыковались LFN записи. В случае только коротких записей цепочку можно писать с любым порядком фрагментов.
В данном случае выполнив поиск 5 последовательностей удалось найти все остальные фрагменты директории с базой 1С.
После того, как построена полная цепочка фрагментов директории, выполняем повторное копирование уже всех файлов 1С базы с предположением об их непрерывности. Пользовательская информация содержится в DBF файлах, поэтому необходимо проверить их целостность.
Основной метод контроля целостности DBF файла – это проверка информации, содержащейся в служебном заголовке и соответствует ли содержимое файла описанию в заголовке.
рис. 10
Первоначально проводится оценка заголовка: проверяется его длина, указанная по смещению 0x08, приводит ли указанное в нем смещение на конечный маркер 0x0D. Записи полей базы, начиная со смещения 0x20, описываются 32-байтовыми записями, в которых по смещению 0x00 следует имя поля, по смещению 0x0B тип поля, по смещению 0x10 – размер поля. Сумма размеров полей +1 (один дополнительный байт для каждой записи в базе является статусом записи в DBF) должна равняться содержимому по смещению 0x0A (размер одной записи в базе). На рисунке DBF файлы мы видим следующие длины полей: 0x09+0x10+0x10+0x10+0x10+0x10+0x01=0x5A.
Проведем проверку корректности размера файла. Для этого выполняем умножение количества записей, которое указано в заголовке по смещению 0x04 на размер одной записи в базе по смещению 0x0A с последующим сложением с содержимым по смещению 0x08.
0x00000003*0x005A+0xE1=0x01EF. По полученному смещению должен находиться маркер окончания файла 0x1A.
Для контроля целостности содержимого полей можно использовать визуальный метод.
рис. 11
В таком вариант просмотра нужно пролистывать содержимое записей от начала и до конца. В случае если заполнение однородное, в каждом поле располагаются типы данных, характерные для описанного в заголовке и инородного содержимого нет, то по завершении просмотра DBF файла можно сделать вывод о корректности его содержимого.
При обнаружении содержимого, не соответствующего описанию поля в заголовке базы, необходимо установить точное место, с которого начинаются некорректные данные.
Рис. 12
Исходя из описания полей в заголовке и содержимого конкретного DBF файла, можно формировать предположительные ASCII последовательности, которые должны находиться по заданным смещениями в недостающих фрагментах. При отсутствии однотипных баз на одном из накопителей (в том числе и файловых копий одной и той же базы) такой метод позволит относительно быстро найти все недостающие фрагменты в образе накопителя. Отдельно отметим, что возникнут дополнительные сложности в стыковке фрагментов, если размер записи в DBF файле маленький или кратен 16. При наличии иных однотипных баз задача будет многократно усложнена (это утверждение справедливо на всех этапах работ, начиная с поиска фрагментов нужной директории).
Необходимо проверить целостность каждого DBF файла, коих в одной 1С базе несколько сотен. По прохождении всех проверок и сборов фрагментов файлов последует финальная проверка в конфигураторе 1С Предприятия.
рис. 13
В идеальном варианте по результатам тестирования должны пройти успешно все пункты, отмеченные в чекбоксах. Если обнаруживаются ошибки по первым двум пунктам, то необходимо проанализировать лог ошибок в конфигураторе и выяснить, в каких DBF файлах присутствуют инородные данные, которые не были обнаружены при проверках. Если обнаруживаются ошибки при проверке логической целостности, то опять же необходимо анализировать лог ошибок, чтобы выяснить, заключается ли проблема базы в качестве ее сбора, либо в ошибках, допущенных разработчиками конфигурации 1С.
Обратим внимание на тот факт, что если бы данная USB flash не была отформатирована, то после ее вычитки процедура восстановления данных была бы значительно более простой, что сильно бы отразилось на стоимости и сроке выполнения работ в меньшую сторону. В заключение, хотелось бы предостеречь всех пользователей и обслуживающий персонал от необдуманных действий в аварийных ситуациях, которые многократно усугубляют проблему, а также пожелать почаще выполнять операции резервного копирования.