Форум: "Базы";
Текущий архив: 2012.03.25;
Скачать: [xml.tar.bz2];
Внизdbf файл - не видно чисел Найти похожие ветки
← →
ruslan_as (2009-09-14 09:00) [0]Приветсвую знатоков. Выручайте: приходят телефонные переговоры в dbf-файлах. Созданы они в какой-то DOS программе (какой - не удается узнать). Проблема в том, что числа в ней проставлены с разделителем точка. Попробовал TDBF - вместо чисел нули. Просмотрел через утилиту в Total Comandere - есть нормальные числа. Через BDE - показывает целые числа (знаки после точкти отсекает) да и BDE использовать мне нельзя. Подскажите, как выкрутиться. Может есть какой компонент который справиться с этой задачей?
← →
Сергей М. © (2009-09-14 09:23) [1]
> приходят телефонные переговоры
Это очень важно для локализации проблемы)
> какой - не удается узнать
http://www.delphikingdom.com/asp/viewitem.asp?catalogid=624
← →
sniknik © (2009-09-14 09:42) [2]> Проблема в том, что числа в ней проставлены с разделителем точка.
это не проблема, это стандарт. даже последний виндовый VFOXPRO так пишет.
> Попробовал TDBF - вместо чисел нули.
значит не так пробовал (насколько знаю он со старыми dos dbf(и dBase и Foxpro) файлами нормально работает, хотя их самих несколько версий...), или причина не в этом.
> Подскажите, как выкрутиться.
не надо выкручиваться, надо нормально работать, проверить формат dbf-а, посмотреть тип полей, и использовать то, что подходит, и правильного типа.
← →
ruslan_as (2009-09-14 12:55) [3]Сергей М. ©. Извините за невежество. Какой программой лучше просмотреть структуру заголовка файла (эти 32 байта).
← →
Сергей М. © (2009-09-14 13:11) [4]
> ruslan_as (14.09.09 12:55) [3]
Да вот прямо той демо-программой, фигурирующей по приведенной ссылке, как раз и можно посмотреть)
← →
ruslan_as (2009-09-14 13:16) [5]Разобрался: простая таблица
Размер заголовка в байтах 97
Размер записи в байтах 19
По таблице остальное "0"
Поле SUMMA (у которого проблема):
тип Numeric
Размер поля 16
Что еще нужно, для того что бы определить тип?
← →
ruslan_as (2009-09-14 13:20) [6]>>Да вот прямо той демо-программой, фигурирующей по приведенной ссылке, как раз и можно посмотреть)
При компиляции выдает Что не может найти файл DBFHeader.res. Пришлось через WinHex.
← →
Сергей М. © (2009-09-14 13:22) [7]
> Поле SUMMA (у которого проблема):
> тип Numeric
> Размер поля 16
А чему, согласно наблюдаемому тобой заголовку этого поля, равно кол-во дробных разрядов ?
По идее оно д.б. равно 2, если речь в поле идет о рублях-копейках ..
← →
Сергей М. © (2009-09-14 13:24) [8]
> не может найти файл DBFHeader.res
Ты бы хоть сообщение до конца дочитал : там ведь тебя спрашивают, создать ли этот файл по причине его отсутствия)
← →
Anatoly Podgoretsky © (2009-09-14 13:47) [9]Для Numeric требуется два поля precision и size
Кроме того никаких программ искать не надо, с Дельфи идет Database Desctop
← →
ruslan_as (2009-09-14 13:48) [10]>>Ты бы хоть сообщение до конца дочитал : там ведь тебя спрашивают, создать ли этот файл по причине его отсутствия)
В том то и дело, что не спрашивает. При запуске dpr пишет сообщение, что не может найти файл. А при компиляции выдает
[Fatal Error] DBFHeader.dpr(6): Unit Windows was compiled with a different version of Types.DWORD. Разбираться не стал.
>>А чему, согласно наблюдаемому тобой заголовку этого поля, равно кол-во дробных разрядов ?
Это я сообразил, что в базе не видно разрядов из-за этого. Только возникают вопросы, почему через другие программы (тот же DOS Navigator или F3 в Total Comander 7 - именно 7, а не ниже ) я вижу эти знаки, а через стандартные компоненты нет? Что тогда делать мне? Изменять в каждом пришедшем файле тип поля?
← →
Anatoly Podgoretsky © (2009-09-14 13:48) [11]Допустим это N16.x тогда еще остается побеспокоиться насчет правильного формата, что не обязательно, особенно для самописного доступа.
← →
ruslan_as (2009-09-14 13:54) [12]Не сочтите за наглость, может у кого будет возможность глянуть мой файл... Не хотелось бы ошибиться в ответе на Ваши вопросы и завести ветку в тупик...
http://rapidshare.com/files/279873434/7202035_03.rar.html
← →
Сергей М. © (2009-09-14 14:11) [13]Поставь в заголовке поля "SUMMA" в поле precision ("Дес.разряд") значение 4.
Что за идиот там поставил 0 и как он додумался до подсчета суммы с точностью до сотых долей копейки - ума не приложу)
← →
Сергей М. © (2009-09-14 14:14) [14]
> Разбираться не стал
Может оно и верно, но следовало бы разобраться, ибо те же грабли , вполне возможно, хлобыстнут позже.
Следовало просто везде, где в проекте встречается слово Types, заменить его на, например, _Types
← →
ruslan_as (2009-09-14 14:15) [15]>>Сергей М. Это программно реализуемо? Потому как это мне прийдется делать ежемесячно... Спасибо за то, что помогаете...
← →
Сергей М. © (2009-09-14 14:20) [16]А ты уже попробовал [13] ?
И убедился что теперь все в порядке ?
Или какртина по-прежнему удручающая ?)
← →
Anatoly Podgoretsky © (2009-09-14 14:32) [17]Судя по всему это самопальный формат или что ни будь особое. Поскольку DBD ругается на попытки просмотра структуры, как раз по поводу размера.
← →
Сергей М. © (2009-09-14 14:47) [18]
> Anatoly Podgoretsky © (14.09.09 14:32) [17]
Угу.
Либо свою прокладку к TDataSet писать либо править prec и size и в заголовке и в теле.
← →
Anatoly Podgoretsky © (2009-09-14 15:31) [19]> Сергей М. (14.09.2009 14:47:18) [18]
Если все понятно с полями, то проще написать прямой доступ к файлу.
Там есть и другие проблемы, например C255 - когда для dBase/FoxPro максимум 254
Другие изначально символьные значения, но с цифрами, определены как N16.0
← →
Сергей М. © (2009-09-14 15:47) [20]
> проще написать прямой доступ к файлу
Да, но ессно при условии, что изменений в структуре этого кривого контейнера в обозримом будущем не предвидится.
← →
ruslan_as (2009-09-14 16:38) [21]Спасибо за советы. Буду биться дальше.
>>Anatoly Podgoretsky
>>проще написать прямой доступ к файлу.
Рассматривая файл как типизированый?
← →
Anatoly Podgoretsky © (2009-09-14 16:45) [22]> ruslan_as (14.09.2009 16:38:21) [21]
Не совсем, поскольку файл состоит из двух частей, заголовка определеной длины и строк данных.
Вместо типизированых объявить две записи, но это в случае если структура постоянная. Иначе предварительный разбор заголовка и дальнейшия работа с типизированым или нет буфером данных под строку.
← →
sniknik © (2009-09-14 17:15) [23]> Там есть и другие проблемы, например C255 - когда для dBase/FoxPro максимум 254
а это не клипер случаем? у него можно и больше. максимум не помню но 255 точно не предел. (файл с работы посмотреть не могу, файлообменники "забанены")
← →
sniknik © (2009-09-14 20:46) [24]это не клипер, BDE показывает что это dBase III (чисто dos формат), но при этом строки там в кодировке win1251... дос просмотрщик на клипере вылетает не открывая этот файл.
+ строка длинной 255
+
>> Проблема в том, что числа в ней проставлены с разделителем точка.
> это не проблема, это стандарт. даже последний виндовый VFOXPRO так пишет.
разделитель там как раз таки запятая, а не точка, а это не стандарт... был бы тип на это строка былобы нормально, но там N, и тип N для чисел с точкой должен определятся как 16.4 например (двумя цифрами, длинной и разрядом, а не одной как в этом файле)
> Судя по всему это самопальный формат или что ни будь особое.
скорее всего так и есть.
← →
Inovet © (2009-09-14 21:15) [25]Foxpro 2.6 и ADS открывают его и поле SUMMA правильно воспринимают.
← →
Anatoly Podgoretsky © (2009-09-15 13:42) [26]> sniknik (14.09.2009 20:46:24) [24]
Ты не обращай внимания, что показывает тот или иной вьювер, невозможно точно определить формат, для этого недостаточно информации, но это не dBase III, поскольку строковые поля длиннее 254, и виндоуская кодировка, чего не может быть по определению, виндоуские кодировки не поддержаны, а для dBase III вообще этого понятия нет, определено как OEM с неизвестной кодировкой, определяется машиной, текущей кодовой OEM CharSet. Мне кажется это самопальная реализация, частично совместимая с dBase III.
По поводу разделителей (Decimal Separator) цифровых форматов всегда точка, но это не должно никого смущать, это внутренний формат хранения, не имеет никакого отношения к формату вывода, формат вывода определяется текущими региональными настройками. Кроме того мне кажется, что "16. " это неухлюжая попытка организации Currency/Моney на формате, который по определению это не поддерживает. Я глубоко влазить не стал, тут решение в организации своего доступа или ручное преобразование таблицы к норме. Второе проще в реализации.
Теперь остается вопрос, зачем так сделано? ответ на это раскроет всю глубину падения разработчика.
← →
Anatoly Podgoretsky © (2009-09-15 13:43) [27]
> Foxpro 2.6 и ADS открывают его и поле SUMMA правильно воспринимают.
Правильно это как?
← →
sniknik © (2009-09-15 14:27) [28]> цифровых форматов всегда точка, но это не должно никого смущать
а меня это и не смутило, меня смутило то что во внутреннем формате там таки запятая... а так никто не записывает (не знаю таких)
> Правильно это как?
ну он воспринимает число записанное в файле в виде 0,998 именно как 0,998 (так и показывает), а не как другие либо со значением 0 либо с #######/Error в поле.
(тоже смотрел, но не посчитал это показателем)
← →
sniknik © (2009-09-15 14:31) [29]> не посчитал это показателем
в смысле, ну оно же ничего не дает, ну меняет кто то предусмотрительно запятую на точку перед преобразованием/или вообще ничего не меняет, отображает строкой... ну и что? вопрос то не в этом, если нужно так любой сможет, но это не делает это его родным форматом.
← →
Anatoly Podgoretsky © (2009-09-15 15:15) [30]> sniknik (15.09.2009 14:27:28) [28]
Ну запятая на совести авторов этого файла.
Ну а касательно чтения, зависит от читателя, некоторые игнорируют это для BCD позиция все равно известна, некоторые более строгие и принимают данные даже с нарушением формата - не тот разделитель, не там, не соответствие количества знаков, выравненый случайным образом, а не по правой границе. За 29 лет столько изращений наделали с форматом dBase, что иногда даже родные продукты иногда игнорируют нарушения, а уж про посторонее и говорить не приходится.
Я опираюсь, на фирменное руководство, где формат отлично описан, кроме кодов языка таблицы для dBase, а в FoxPro и коды языков указаны. И на всякий случай в части русского эти коды отличаются, а в Интернет бардак, часто коды FoxPro приписывают dBase
← →
Inovet © (2009-09-15 15:19) [31]> [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"
Вывод. Для читалки проще, как выше предлагали, прямое чтение файла.
← →
Anatoly Podgoretsky © (2009-09-15 15:20) [32]Наверно ты встречался с таким извращением, как запись двоичных данных в текстовое поле, язык и поддержка это позволяли, по крайней мере до появления БДЕ.
← →
Inovet © (2009-09-15 15:36) [33]> [32] Anatoly Podgoretsky © (15.09.09 15:20)
> Наверно ты встречался с таким извращением, как запись двоичных
> данных в текстовое поле, язык и поддержка это позволяли,
> по крайней мере до появления БДЕ.
Видел такое.
Да в оригинале было на C++Builder, с автоматическим приведением
ShowMessage(t->FieldByName("SUMMA")->AsFloat);
но не суть.
← →
... (2010-05-11 16:51) [34]Удалено модератором
Примечание: Отдельный вопрос, отдельная ветка
← →
Sergey13 © (2010-05-11 17:00) [35]> [34] ... (11.05.10 16:51)
> как обойти проблемку???
Программиста надо вызывать, а не поднимать ветки годичной давности.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2012.03.25;
Скачать: [xml.tar.bz2];
Память: 0.54 MB
Время: 0.003 c