1с 8 не работает dbf
всем привет! есть старая прога (на фокспро), которая хранит информацию в дбф-файле. нужно настроить обмен: из 1С добавлять туда новые записи. проблема в том, что в этой файле есть memo поля. просто добавить через XBase не получается. установили на серваке фокспро 9. пытаюсь подключится через ADODB к файлу. не получается. Произошла исключительная ситуация (Microsoft OLE DB Provider for ODBC Drivers): [Microsoft][Диспетчер драйверов ODBC] Источник данных не найден и не указан драйвер, используемый по умолчанию на серваке: windows 2012. а odbc драйвер 32 разрядный может в этом проблема?
1С на серваке тоже 64 разрядная. когда в кофигураторе создаю новый внешний источник данных, видит только драйвер скл .
со своего компа windows 7 получилось подключиться к дбф-ке. в т.ч. считать поля memo вопрос 1: в чем разница между первым моим подключением (через драйвер) и нынешним (через провайдер)? вопрос 2. все таки дело в разрядности виндовса? на серваке не работает также.
разница в том, что в первом случае вы пытаетесь использовать провайдер для odbc, который, в свою очередь, должен читать файл через драйвер odbc. Во втором случае вы используете провайдер visual fox pro, который работает с файлом напрямую.
Битность провайдеров должна совпадать с битностью процесса. Т.е. для сервака надо найти 64-битные провайдеры
ок. понял. спасибо. а на сервере не работает именно из-за разрядности? вообще в природе есть фокс про 64 для виндовс сервер 2012?
Вообще поскольку ADO/OLEDB технология от Майкрософт, то я там бы и поискал провайдеров, могут быть вполне
В нулевые годы Microsoft заявила, что разрабатывать 64-разрядную версию foxpro считает нецелесообразным и тем самым похоронила foxpro.
смотрю на серваке в администрировании "Источники данных ODBC (64-разрядная версия)" там в драйверах только SQL Server стоит.
ошибку выдает: Произошла исключительная ситуация (Microsoft OLE DB Provider for Visual FoxPro): Must specify additional parameters.
не идет все равно. не добавляется запись. видимо, как понимаю надо описать типы полей. Как это сделать?
посмотрите в сторону провайдера для Access, вполне может быть что он делает то что вам надо. Он 64-битный - есть, скачивается с MS бесплатно
в общем, получилось добавить запись) неправильно указывал значения. строка в одинарных кавычках, число без кавычек через точку в дробной части, булево - .f. или .t. теперь осталось разобраться с разрядностью.
еще вопрос возник. а есть какие-нить механизмы блокировки дбф-файла в момент когда я записи свои буду добавлять?
Если мне память не изменяет, то foxpro при начале добавления записи автоматически делает блокировку заголовка и снимает по окончании. По логике в твоем случае эту работу автоматически должен делать драйвер.
пробую через акцес: не открывается. ошибка: <ВнешняяОбработка.ВыгрузкаВДБФ.Форма.Форма.Форма>: Ошибка при вызове метода контекста (Open) ОлеДБ.Open(Соединение); по причине: Произошла исключительная ситуация (Microsoft Access Database Engine): Could not find installable ISAM. провайдера мож неправильно указываю?ВнешняяОбработка.ВыгрузкаВДБФ.Форма.Форма.Форма>
СтрокаПодключения="DRIVER=
Боже мой, сколько (уж извините за резкость) чуши на ровном месте. 1. Фокс только 32-битный и дрова к нему тоже только 32-битные. 2. Список 32-битных дров на 64-юитных системах отдельный и никак не связан со списком 64-битных дров. 3. OLE DB Provider и ODBC - две разных технологии построения драйверов доступа к базам данных. конкретно для фокса ODBC драверы дрвнее мамонтов. Все фоксовые форматы дбф поддерживает только VFP OLE DB Provider. 4. Во спасение от будущих граблей :) - даты надо писать в формате В принципе, сего должно хватить для решения обсуждаемой пробемы. Разумеется, если это использовать с головой. :_^yyyy-mm-dd>
это мы уже выяснили. с 32-х битного виндовса нормально подключаюсь через VFP OLE DB Provider. все работает. ты уж извини меня неумного, но то, что ты перечислил - все это уже мы выяснили выше. конкретно как с сервера 64 разрядного подключится к дбф-ке?
Добавчик: 5. В подавляющем большинстве случаев сервер 1с 32-битный и потому во всех этих случаях ни о каких 64-битных дровах не может быть и речи.
Да, похоже, таки еще не выяснили, раз такой вопрос задаешь. Ну так и что непонятно из ? 64-битные приложения в принципе не умеют пользоваться 32-битными дровами. Работать исключительно из 1с-вского клиента, даже если он и вместе сервером 1с на одной машине.
на локальной базе все норм работает. на серваке: <ВнешняяОбработка.ВыгрузкаВДБФ.Форма.Форма.Форма>: Ошибка при вызове метода контекста (Open) DBConn.Open("Provider=Microsoft.Jet.OLEDB.4.0;" + по причине: Произошла исключительная ситуация (ADODB.Connection): Не удается найти указанный поставщик. Вероятно, он установлен неправильно.ВнешняяОбработка.ВыгрузкаВДБФ.Форма.Форма.Форма>
подскажите синтаксис добавления даты в моем случае? "INSERT INTO DOGOVOR VALUES ("+ДатаВ+")" ошибка синтаксиса говорит
не идет так. Произошла исключительная ситуация (Microsoft OLE DB Provider for Visual FoxPro): Произошла одна или несколько ошибок во время обработки команды.
мда.. спасибо тебе (это не сарказм). у меня пока сохраняется вера в человечество. пока правильного намёка достаточно. и ответного "спасибо", конечно ;)
всем привет! это снова я) в общем, получилось подключиться к дбф-ке через Provider = Microsoft.Ace.OLEDB.12.0 с сервака64. но проблема в том, что с мемо полями, как я понял, этот провайдер не работает (другие дбф-ки без мемо полей читает норм). все-таки как Епрст подключается через Provider=VFPOLEDB.1? у меня упорно провайдера не видит. драйвер установлен также по ссылке как в . скидываю скрин источников данных на серваке, смущает дата драйвера (1999 год). может в этом проблема?
Например, создадим файл, идентичный по структуре исходному.
//При этом применяется метод ОписаниеПоля, который возвращает характеристики поля с указанным номером
//синтаксис: ОписаниеПоля(,,,,)
Для работы с файлом DBF неизвестной структуры часто применяются следующие методы:
ПолучитьЗначениеПоля();
УстановитьЗначениеПоля(,);
Работа с удаленными записями
Файлы DBF устроены таким образом, что удаление записи не приводит к физическому удалению записи из файла. Запись просто помечается на удаление и пропускается при переборе. Таким образом размер файла остается прежним. Чтобы физически удалить все помеченные на удаление записи нужно применить метод Сжать. Средства встроенного языка позволяют работать с такими записями, перебирать их и даже отменять пометку на удаление.
Можно удалить все записи в файле одним движением. При этом они физически удаляются и не могут быть восстановлены.
Стоит еще отметить про метод Очистить(), что он очищает все поля текущей записи. Атрибуты, соответствующие полям типа "строковый" приобретают значение «пустая строка», числовой — 0, логический — 0, дата — «пустая дата».
Работа с индексами
Для организации упорядочивания содержимого файла БД и поиска в ней по значению одного или нескольких полей применяется механизм индексов. Его применение можно сравнить с сортировкой картотеки по определенному признаку (совокупности признаков). Однако, в отличие от картотеки, файл БД может иметь сразу несколько индексов, и, соответственно, являться упорядоченным одновременно по нескольким признакам. Индексы хранятся в индексном файле. Индексный файл может содержать информацию более чем об одном индексе. Рекомендуется для одного файла DBF иметь один индексный файл, в котором хранятся все индексы для этого файла.
Каждый индекс имеет наименование, признак уникальности, выражение индекса и фильтр. Наименование индекса используется для идентификации индекса. Выражение индекса и фильтр представляют собой написанные на специальном языке выражения, вычисление значения которых для каждой записи позволяет определить ее место при упорядочивании и необходимость помещения ее в упорядоченный список (индекс может содержать упоминание не обо всех записях таблицы, а только об удовлетворяющих выражению фильтра). Уникальный индекс (имеющий установленным признак уникальности) позволяет иметь в индексе ссылки на записи только с различным значением индексного выражения.
Основное правило: индекс нужен, чтобы быстро искать нужную запись.
Нужно быстро найти Комаров. В неупорядоченном исходном файле искать его можно только последовательным перебором всех записей, что будет очень долго при большом числе записей. В индексе найти Комарова можно очень быстро, поскольку индекс отсортирован по полю Фамилия. При этом мы узнаем физический номер записи в файле DBF и производим прямое позиционирование на нужную запись.
После создания структуры базы данных можно добавить индексы следующим образом:
//Синтаксис: ДобавитьИндекс(, , , , )
После сбоя рекомендуется заново переформировать все индексы
В 1С существует специальный язык для задания выражений и фильтра индекса. Подробнее о нем, смотрите в документации на встроенный язык.
Отбор по значению поля
Часто возникают вопросы по фильтрации файла БД по значению
определенного поля.
Предположим , что в предыдущем примере сотрудники работают в разных
подразделениях «Офис» и «Филиал» ,
и нужно вывести всех сотрудников работающих в офисе.
Нетрудно увидеть, что в языке нет явных способов получить записи
по фильтру, но имея индекс тем не менее, данную операцию
можно эффективно (без перебора всех записей) осуществить.
1. Создадим файл индекса, если он ранее не был создан
2. Откроем Файл базы с индексом
3.Прейдем на первую запись
4. И так как все записи упорядочены по индексу - достаточно пройтись
по записям, пока не встретится запись с другим значением поля "Otdel" :
Протестируйте качество нашей работы - получите первую консультацию в подарок.
Одним из самых распространенных форматов баз данных до сих пор остается формат DBF. И неумение работать с ним из 1С – серьезное ограничение профессиональных навыков для любого специалиста. Тем более изучение теории и практика по этому вопросу потребует совсем немного времени. К тому же работа с DBF файлом никаких дополнительных библиотек не требует – все инструменты встроены в платформу 1С 8.3.
Чтение, создание DBF и запись в данный формат
Вся работа с DBF в 1С происходит с помощью специального объекта – xBase. Рассмотрим основные действия с файлами, начав с чтения из конкретного DBF. В первую очередь необходимо расположить файл базы данных в каталоге, куда есть доступ у пользователя. Код для считывания данных в 1С достаточно прост:
- Указываем путь к базе в формате DBF;
- Создаем объект для взаимодействия с файлом, открываем его и устанавливаем указатель на первую строку с данными;
- В цикле обходим всю базу и производим действия с элементами. В данном случае просто отражаем их на экране пользователя;
- Закрываем файл.
Вторая часто встречающаяся задача по взаимодействию с объектом – выгрузка DBF из 1С 8.3. Здесь намного легче создать конечный файл нужного формата программно, чем использовать дополнительно программное обеспечение. Этот алгоритм в 1С тоже достаточно прост и состоит из нескольких строк кода:
- Создаем объект XBase;
- Определяем кодировку нового файла. Существует кодировка для Windows – ANSI и OEM предназначенная для DOS;
- Необходимо описать все колонки будущего файла DBF, указав их тип;
- Укажем каталог, в котором будет происходить создание DBF и запишем итоговый файл.
Рис.1 Расположение файлов DBF
После того как мы создали файл нужного формата, потребуется выгрузка в DBF данных. Программируя этот процесс, помните о том, что данные ИБ находятся на сервере. Чтобы записать имеющиеся данные из 1С необходимо к предыдущему коду добавить следующий алгоритм:
- Получаем информацию из справочника;
- В цикле последовательно добавляем по 1строчке и записываем;
- Закрываем файл и проверяем, что запись прошла удачно.
Это основы работы с данным форматом. Существуют и другие способы открыть из 1С DBF, но xBase остается самым простым по синтаксису и пониманию. Поняв, как осуществляется простейшая выгрузка и загрузка из DBF, можно приступать к более сложным элементам, например, использованию индексов для поиска, удалению или изменению конкретных записей в DBF, а также применению технологии ADO.
В 1С 8.3 для операций с DBF есть стандартный объект XBase, позволяющий работать непосредственно из встроенного языка . Формат хранения файлов баз данных DBF (dBase III) , используемый в качестве одного из стандартных способов хранения информации в системах управления базами данных. Имеет двумерный массив (таблица) и часто используется программами 1С с самых ранних версий. В 1С 8.3 DBF может использоваться программистами для обмена со сторонними приложениями и базами данных. Данный формат устарел из из-за своих ограничений:
✔ Чтение записей файла в формате *.DBF
&НаКлиенте
Процедура ЧтениеЗаписейФайлаВФорматеDBF ( ПутьКФайлуDBF )
ТаблицаDBF = Новый XBase ;
ТаблицаDBF . ОткрытьФайл ( ПутьКФайлуDBF ,,Истина); // путь к базе, путь к индексу - необязателен, только чтение
Сообщить ( "Таблица DBF имеет кодировку: " + ТаблицаDBF . Кодировка );
Сообщить ( "В таблице " + ТаблицаDBF . КоличествоЗаписей () + " записей." );
ТаблицаDBF . Первая (); // перешли к первой записи
Пока Не ТаблицаDBF . ВКонце () Цикл //не последняя запись
Если Не ТаблицаDBF . ЗаписьУдалена () Тогда //нет пометки на удаление
Сообщить ( ТаблицаDBF . Kod + " " + ТаблицаDBF . Country + " " + Строка ( ТаблицаDBF . Population ) + " " + ТаблицаDBF . Continent );
КонецЕсли;
ТаблицаDBF . Следующая (); // переходим к следующей записи
КонецЦикла;
ТаблицаDBF . ЗакрытьФайл ();
&НаКлиенте
Процедура ПоискНужнойЗаписиВФайлеВФорматеDBF ( ПутьКФайлуDBF )
// Файлы dbf могут быть очень большими и содержать тысячи записей.
// В этом случае полный перебор всех записей,
// чтобы найти одну - плохая идея - поиск будет долгим.
ТаблицаDBF = Новый XBase ;
ТаблицаDBF . ОткрытьФайл ( ПутьКФайлуDBF ,,); // путь к базе, путь к индексу, открываем на запись (Ложь)
// Но для того, чтобы искать по ключу - нужен индексный файл, включающий нужные нам поля. Если бы этот файл уже был у нас,
// то мы бы передали его при открытии файла вышле, но у нас его нет, а потому - займёмся его созданием.
// создадим индекс только по полю Population
ТаблицаDBF . Индексы . Добавить ( "INDEX_Population" , "Population" , ); // имя индекса, выражение индекса, уникальность создаваемого индекса (Истина)
КаталогDBFФайлов = "D:\World" ;
СоздатьКаталог ( КаталогDBFФайлов );
ПутьКФайлуИндекса = КаталогDBFФайлов + "\kldr.cdx" ; //имя файла не более 8 символов (включая расширение)
ТаблицаDBF . СоздатьИндексныйФайл ( ПутьКФайлуИндекса );
// Заново открываем таблицу, уже на чтение и с индексным файлом, который мы только что создали.
ТаблицаDBF = Новый XBase ;
ТаблицаDBF . ОткрытьФайл ( ПутьКФайлуDBF , ПутьКФайлуИндекса ,Истина); // путь к базе, путь к индексу, только чтение
// Найдём среди записей ту, у которой поле Population равно 10.
// В таблице всего один индекс INDEX_Population.
ТаблицаDBF . ТекущийИндекс = ТаблицаDBF . Индексы . Получить ( 0 );
ТаблицаDBF . Ключ . Population = "10" ;
ЗаписьНайдена = ТаблицаDBF . НайтиПоКлючу ( " Запись найдена" );
Сообщить ( ТаблицаDBF . Kod + " " + ТаблицаDBF . Country + " " + Строка ( ТаблицаDBF . Population ) + " " + ТаблицаDBF . Continent );
Иначе
Сообщить ( "Запись не найдена" );
КонецЕсли;
Как выяснилось, резервная копия данной базы у клиента более, чем годовой давности.
Первый этап в решении подобных задач – это создание поблочной копии оригинального накопителя (или как принято писать со времен, когда носителями были только накопители на гибких и жестких магнитных дисках – посекторной). При вычитывании обнаруживается нестабильная скорость чтения, что говорит о серьезном износе 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 не была отформатирована, то после ее вычитки процедура восстановления данных была бы значительно более простой, что сильно бы отразилось на стоимости и сроке выполнения работ в меньшую сторону. В заключение, хотелось бы предостеречь всех пользователей и обслуживающий персонал от необдуманных действий в аварийных ситуациях, которые многократно усугубляют проблему, а также пожелать почаще выполнять операции резервного копирования.
Читайте также: