> проще написать прямой доступ к файлу


Да, но ессно при условии, что изменений в структуре этого кривого контейнера в обозримом будущем не предвидится.

Спасибо за советы. Буду биться дальше.

>>Anatoly Podgoretsky
>>проще написать прямой доступ к файлу.

Рассматривая файл как типизированый?

> ruslan_as  (14.09.2009 16:38:21)  [21]

Не совсем, поскольку файл состоит из двух частей, заголовка определеной длины и строк данных.
Вместо типизированых объявить две записи, но это в случае если структура постоянная. Иначе предварительный разбор заголовка и дальнейшия работа с типизированым или нет буфером данных под строку.

> Там есть и другие проблемы, например C255 - когда для dBase/FoxPro максимум 254
а это не клипер случаем? у него можно и больше. максимум не помню но 255 точно не предел. (файл с работы посмотреть не могу, файлообменники "забанены")

это не клипер, BDE показывает что это dBase III (чисто dos формат), но при этом строки там в кодировке win1251... дос просмотрщик на клипере вылетает не открывая этот файл.
+ строка длинной 255
+
>> Проблема в том, что числа в ней  проставлены с разделителем точка.
> это не проблема, это стандарт. даже последний виндовый VFOXPRO так пишет.
разделитель там как раз таки запятая, а не точка, а это не стандарт... был бы тип на это строка былобы нормально, но там N, и тип N для чисел с точкой должен определятся как 16.4 например (двумя цифрами, длинной и разрядом, а не одной как в этом файле)

> Судя по всему это самопальный формат или что ни будь особое.
скорее всего так и есть.

Foxpro 2.6 и ADS открывают его и поле SUMMA правильно воспринимают.

> sniknik  (14.09.2009 20:46:24)  [24]

Ты не обращай внимания, что показывает тот или иной вьювер, невозможно точно определить формат, для этого недостаточно информации, но это не dBase III, поскольку строковые поля длиннее 254, и виндоуская кодировка, чего не может быть по определению, виндоуские кодировки не поддержаны, а для dBase III вообще этого понятия нет, определено как OEM с неизвестной кодировкой, определяется машиной, текущей кодовой OEM CharSet. Мне кажется это самопальная реализация, частично совместимая с dBase III.

По поводу разделителей (Decimal Separator) цифровых форматов всегда точка, но это не должно никого смущать, это внутренний формат хранения, не имеет никакого отношения к формату вывода, формат вывода определяется текущими региональными настройками. Кроме того мне кажется, что "16. " это неухлюжая попытка организации Currency/Моney на формате, который по определению это не поддерживает. Я глубоко влазить не стал, тут решение в организации своего доступа или ручное преобразование таблицы к норме. Второе проще в реализации.

Теперь остается вопрос, зачем так сделано? ответ на это раскроет всю глубину падения разработчика.

> Foxpro 2.6 и ADS открывают его и поле SUMMA правильно воспринимают.

Правильно это как?

> цифровых форматов всегда точка, но это не должно никого смущать
а меня это и не смутило, меня смутило то что во внутреннем формате там таки запятая... а так никто не записывает (не знаю таких)

> Правильно это как?
ну он воспринимает число записанное в файле в виде 0,998 именно как 0,998 (так и показывает), а не как другие либо со значением 0 либо с #######/Error в поле.
(тоже смотрел, но не посчитал это показателем)

> не посчитал это показателем
в смысле, ну оно же ничего не дает, ну меняет кто то предусмотрительно запятую на точку перед преобразованием/или вообще ничего не меняет, отображает строкой... ну и что? вопрос то не в этом, если нужно так любой сможет, но это не делает это его родным форматом.

> sniknik  (15.09.2009 14:27:28)  [28]

Ну запятая на совести авторов этого файла.
Ну а касательно чтения, зависит от читателя, некоторые игнорируют это для BCD позиция все равно известна, некоторые более строгие и принимают данные даже с нарушением формата - не тот разделитель, не там, не соответствие количества знаков, выравненый случайным образом, а не по правой границе. За 29 лет столько изращений наделали с форматом dBase, что иногда даже родные продукты иногда игнорируют нарушения, а уж про посторонее и говорить не приходится.
Я опираюсь, на фирменное руководство, где формат отлично описан, кроме кодов языка таблицы для dBase, а в FoxPro и коды языков указаны. И на всякий случай в части русского эти коды отличаются, а в Интернет бардак, часто коды FoxPro приписывают dBase

> [27] Anatoly Podgoretsky ©   (15.09.09 13:43)
>
> > Foxpro 2.6 и ADS открывают его и поле SUMMA правильно
> воспринимают.
>
> Правильно это как?

И действительно как. Я предположил под "правильно" это с 4-мя знаками после точки. Вот пробую ещё раз.

Foxpro 2.6.
В браузере показывает правильно, но в выражениях дробная часть отбрасывается.

ADS.
Обращаюсь так
ShowMessage(t.FieldByName("SUMMA").AsFloat);
ShowMessage(q.FieldByName("SUMMA").AsFloat);

где
t TAdsTable;
q TAdsQuery;
q.SQL.Text := 'SELECT SUMMA FROM T';

получаю ожидаемое значение

SELECT SUMMA*1 AS SUMMA FROM T
Совсем не то

SELECT SUMMA-0 AS SUMMA FROM T
"The given data type is not valid for the requested operation. Expected the numeric value"

Вывод. Для читалки проще, как выше предлагали, прямое чтение файла.

Наверно ты встречался с таким извращением, как запись двоичных данных в текстовое поле, язык и поддержка это позволяли, по крайней мере до появления БДЕ.

> [32] Anatoly Podgoretsky ©   (15.09.09 15:20)
> Наверно ты встречался с таким извращением, как запись двоичных
> данных в текстовое поле, язык и поддержка это позволяли,
> по крайней мере до появления БДЕ.

Видел такое.

Да в оригинале было на C++Builder, с автоматическим приведением
ShowMessage(t->FieldByName("SUMMA")->AsFloat);
но не суть.

Удалено модератором
Примечание: Отдельный вопрос, отдельная ветка

> [34] ...   (11.05.10 16:51)
> как обойти проблемку???

Программиста надо вызывать, а не поднимать ветки годичной давности.