некоректное чтение .dbf созданного в foxpro (dos)

← →
msgipss (2003-02-10 19:00) [0]

Существует программа написанная на Foxpro 2.5, которая пишет какой то набор кодов в табличку .dbf. Я открываю эту табличку либо с помошью bde либо THalcyonDataSet, считываю строку, и получаю не всегда корретную, а иногда и пустую, хотя в фоксе открываю и получаю набор кодов. Как мне корректно прочитать строку. Если открывать табличку как двоичный файл, то я считываю то что мне нужно. Кто сталкивался помогите плиз, очень нужно
Заранее спасибо

← →
sniknik © (2003-02-10 20:45) [1]

LANGDRIVER поставь "ascii" ANSI, чтобы не было попыток переконвертить OEM to ANSI.

← →
msgipss (2003-02-11 05:10) [2]

а где ставить то ???
в BDE ясно где, а в THalcyonDataSet как ???

← →
sniknik © (2003-02-11 08:31) [3]

> либо с помошью bde либо THalcyonDataSet
???
ну и работай с BDE.

для Halcyon свойство компанента
property TranslateASCII: boolean;
в фалсе
и скачай свежую версию (6.95 если правильно помню) как раз бала скоректирована работа с перекодировкой русских буковок.

← →
msgipss (2003-02-11 15:32) [4]

Проблема не срускими буквами. В поле таблички идут коды символов, например: #0#2 и т.д., так вот эти строки не отображаються, т.е. как только в строке встречаеться #0 то получаеться что бде что THalcyonDataSet не передают строку. А мне нужно получить полную строку в 120 символов, т.к. эти 120 символов есть реально, но не читаются под виндами, это проблема кстати не только дэльфей но и визуал басика и самого визуал фоксаю. Кто пытался решать данный проблемс - отзовитесь.
Все вышеописанное я конечно пробовал но безрезультатно

← →
sniknik © (2003-02-11 15:58) [5]

про #0 в строке ты ничего не говорил.
это все меняет, если бы не он то проблема именно с перекодировкой т.к. некоторые лангдрайвера игнорируют символы им не понятные (управляющие до #32, псевдографику ...)

а #0 и #32 могут быть символами дополняющими строку, (dbf это же текст, поля хранятся дополнеными до обьявленого размера, те. если поле CHAR(30) а туда сохраняют 1 символ то запишется символ+SPAСE(29) или символ+#0-29раз) причем #0 пишут не все, поддерживать пытаются многие и в случае с #0 получается ASCI-Z строка ( завершающаяся нулем).
Решить в BDE невозможно, в Halcyon без проблем, есть же исходники! сам убирал усечение строки (нужно было для совместимости по индексам, в индексном выражении использовлась полная стрка). Все что нужно, пол часа трассировки. И закоментарить 1 (одну) строку с вызовом процедуры усечения.

← →
msgipss (2003-02-11 16:06) [6]

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

У тебя случаем нет Halcyon с исходниками.. 8)

если бы у меня не было исходников то и сам Halcyon нужен был бы как собаке пятая нога. бери сдесь.
http://www.vodonosov.newmail.ru/develop/develop.htm

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

← →
msgipss (2003-02-11 16:46) [8]

Большое СПАСИБО , за оперативную помощь.
Если есть в БК, может когда и встретимся, хотя врятли
спасибо, буду пробовать...

← →
msgipss (2003-02-12 07:38) [9]

У меня получилось !!!!
с твоей подсказкой заняло 4 минуты.
с компонентом явно быстрее будет вместо прямого доступа, индексы как никак.
Щас буду пробовать в многопоточном варианте, как думаешь 200 потоков в каждом по компоненту, как много памяьти отъест.
Еще раз спасибо

некоректное чтение .dbf созданного в foxpro (dos) Найти похожие ветки