Приветсвую знатоков. Выручайте: приходят телефонные переговоры в dbf-файлах. Созданы они в какой-то DOS программе (какой - не удается узнать). Проблема в том, что числа в ней  проставлены с разделителем точка. Попробовал TDBF - вместо чисел нули. Просмотрел через утилиту в Total Comandere - есть нормальные числа. Через BDE - показывает целые числа (знаки после точкти отсекает) да и BDE использовать мне нельзя. Подскажите, как выкрутиться. Может есть какой компонент который справиться с этой задачей?

> приходят телефонные переговоры


Это очень важно для локализации проблемы)


> какой - не удается узнать


http://www.delphikingdom.com/asp/viewitem.asp?catalogid=624

> Проблема в том, что числа в ней  проставлены с разделителем точка.
это не проблема, это стандарт. даже последний виндовый VFOXPRO так пишет.

> Попробовал TDBF - вместо чисел нули.
значит не так пробовал (насколько знаю он со старыми dos dbf(и dBase и Foxpro) файлами нормально работает, хотя их самих несколько версий...), или причина не в этом.

> Подскажите, как выкрутиться.
не надо выкручиваться, надо нормально работать, проверить формат dbf-а, посмотреть тип полей, и использовать то, что подходит, и правильного типа.

Сергей М. ©. Извините за невежество. Какой программой лучше просмотреть структуру заголовка файла (эти 32 байта).

> ruslan_as   (14.09.09 12:55) [3]


Да вот прямо той демо-программой, фигурирующей по приведенной ссылке, как раз и можно посмотреть)

Разобрался: простая таблица
Размер заголовка в байтах 97
Размер записи в байтах 19
По таблице остальное "0"

Поле SUMMA (у которого проблема):
тип Numeric
Размер поля 16
Что еще нужно, для того что бы определить тип?

>>Да вот прямо той демо-программой, фигурирующей по приведенной ссылке, как раз и можно посмотреть)
При компиляции выдает Что не может найти файл DBFHeader.res. Пришлось через WinHex.

> Поле SUMMA (у которого проблема):
> тип Numeric
> Размер поля 16


А чему, согласно наблюдаемому тобой заголовку этого поля, равно кол-во дробных разрядов ?

По идее оно д.б. равно 2, если речь в поле идет о рублях-копейках ..

> не может найти файл DBFHeader.res


Ты бы хоть сообщение до конца дочитал : там ведь тебя спрашивают, создать ли этот файл по причине его отсутствия)

Для Numeric требуется два поля precision и size
Кроме того никаких программ искать не надо, с Дельфи идет Database Desctop

>>Ты бы хоть сообщение до конца дочитал : там ведь тебя спрашивают, создать ли этот файл по причине его отсутствия)
В том то и дело, что не спрашивает. При запуске dpr пишет сообщение, что не может найти файл. А при компиляции выдает
[Fatal Error] DBFHeader.dpr(6): Unit Windows was compiled with a different version of Types.DWORD. Разбираться не стал.

>>А чему, согласно наблюдаемому тобой заголовку этого поля, равно кол-во дробных разрядов ?
Это я сообразил, что в базе не видно разрядов из-за этого. Только возникают вопросы, почему через другие программы (тот же DOS Navigator или F3 в Total Comander 7 - именно 7, а не ниже ) я вижу эти знаки, а через стандартные компоненты нет? Что тогда делать мне? Изменять в каждом пришедшем файле тип поля?

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

Не сочтите за наглость, может у кого будет возможность глянуть мой файл... Не хотелось бы ошибиться в ответе на Ваши вопросы и завести ветку в тупик...
http://rapidshare.com/files/279873434/7202035_03.rar.html

Поставь в заголовке поля "SUMMA" в поле precision ("Дес.разряд") значение 4.
Что за идиот там поставил 0 и как он додумался до подсчета суммы с точностью до сотых долей копейки - ума не приложу)

> Разбираться не стал


Может оно и верно, но следовало бы разобраться, ибо те же грабли , вполне возможно, хлобыстнут позже.

Следовало просто везде, где в проекте встречается слово Types, заменить его на, например, _Types

>>Сергей М.   Это программно реализуемо? Потому как это мне прийдется делать ежемесячно...  Спасибо за то, что помогаете...

А ты уже попробовал [13] ?
И убедился что теперь все в порядке ?
Или какртина по-прежнему удручающая ?)

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

> Anatoly Podgoretsky ©   (14.09.09 14:32) [17]


Угу.

Либо свою прокладку к TDataSet писать либо править prec и size и в заголовке и в теле.

> Сергей М.  (14.09.2009 14:47:18)  [18]

Если все понятно с полями, то проще написать прямой доступ к файлу.
Там есть и другие проблемы, например C255 - когда для dBase/FoxPro максимум 254
Другие изначально символьные значения, но с цифрами, определены как N16.0

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


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

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

>>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)
> как обойти проблемку???

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