Задача. Периодически читать данные из файлов Btrieve 6.0. Родная программа с этой базой работает без DDF-файлов.

Очень удачно начался у меня процесс по созданию DDF-заголовков таблиц из среды Pervasive Control Center (PCC) пакета PSQL 2000i SP3 Workstation (PSQL2000iSP3W). Имеется некоторая информация о структуре данных для требуемых таблиц. Для небольшой таблицы (около 15 полей) все прошло удачно, удалось подцепить, данные видно прекрасно.

Другая таблица очень большая - более 200 полей. Есть частичная информация об этих полях. С помощью утилиты PSQL butil точно определена длина записи. Нужные поля нахожу и описываю как надо, а промежутки заполняю полями типа zstring[L] так, что общая длина записи равна определенной через butil.

Проблема. N-поле типа по документации mdate[4]. Делаю ее как date[4], типа mdate нет. Следующее (N+1)-е поле типа zstring[101]. Все значения его хорошо видны. Но значения N поля не все корректны. Точнее все значения даты 01-го месяца показаны как некорректные, а остальные дают на 1 месяц меньше. Пустяковый случай... Переделываю тип поля N на integer[4] и расчитываю заняться им в программе вручную. Но в записях с "некорректными" датами часть информации в этом случае после этого поля N, т.е. начиная с поля (N+1) становятся пустыми или нулевыми, но не до конца записи а до некоторого поля M ближе к концу записи.

Что это за "глюк", и как быть, подскажите, пожалуйста?

Пробовал zstring[4] и некоторые другие типы[4], но результат такой же!!!???
Да!!! Такой же результат дает родная утилита PSQL butil -save. Такой же результат дает встроенная в родную старую программу утилита перевода таблиц в dbf. А вот другая родная из старой программы утилита дает корректный выброс инфы в dbf, жаль что только недостаточный по полям, т.е. она этот экспорт ограничен по полям таблицы...

Использование типа lstring с первым символом длины в одном из полей N или (N+1) приводит при просмотре из PCC к ругани о недостаточном буфере. Массив символов, полагаю, char. Его я тоже активно тестировал. Результат не меняется.

Еще раз обращаю внимание, что утилите butil -save тоже дает сбойный результат.

Самое интересное, что когда 4-е поле date[4] и 5-е поле zstring[61], то все чедесно, почти как надо!!! Разве что даты смещены на один месяц, а некоторые показаны некорректными , из-за чего с таким набором невожно работать, например, из Делфи. Может быть попытаться разобраться с 4-м полем?

Напомню, что если изменить его тип на какой-либо другой тип[4], то после этого множество полей справа от него показаны пустыми строками или нулевыми значениями, а к концу записи значения полей "восстанавливаются"!!!

Как быть? Такое подозрение, что родная DOS-программа изменила структура сандарта файла Btrieve 6.00...

Альтернативный вопрос. Почему утилита butil -save выкидывет также некорректно (т.е. часть данных как описано занулена). Я был бы рад работать и с результатом этого преобразования таблицы в "аля-текстовый" вид. :)

Я не пояснил. Я не пытаюсь работать с таблице без DDF. Я в PCC пытаюсь создать новую базу с существующей таблицей в режиме совместимости версии Btrieve 6.X. Для этого в PCC захожу в Дизайн Таблы с выставленной опцией "Не трогать сами данные (то бишь содержимое файла) и по доке пытаюсь восстановить структуру. С небольшой таблицей все закончилось на ура. А вот с большой возникли описанные здесь проблемы. :(

Вот незадача!!! Оказывается от смены типа столбца PCC меняет порядок строк при простом SELECT (двойной клик на таблицу). Это просто НЕ НОРМАЛЬНО!!!
Это меня завело в заблуждение, поскольку я считал, что появляется больше "пробелов", а на самом деле "больше-пробельные" строки перетягивались на верх. Так оно и оказалось в действительности.
И второе, тип дата действительно не поддерживается в PSQL2000iSP3 от таблиц Btrieve 6.0, по-любому, у меня так и не вышло это, но не беда - обойдусь unsigned[4].
Спасибо, golsa!!!