BDE + .dbf (ограничение String)

[Аватар]

Что-то не понял ваших проблем и что имеет ввиду Serge_Bliznykov тоже не понял. В выложеной болванке нет длинных символьных полей, FoxPro нормально открыл, VFoxPro нет, открыл тремя разными ADO-шными провайдерами без проблем, как насчет кодировки не вижу - данных нет. Возможно сами данные испорчены? Как это может привести к символьному полю 700 байт не догоняю

[alexiz]

Табличка нормальная. Лично я в ней ничего левого не рассмотрел.

Записал в нее строку 400 символов в поле AD2_TXP и не чирикнула.

Использовал VKDBF.

[Аватар]

AD2_TXP интересное описание - символьное поле с длиной 188 и двумя знаками после точки. В этом наверно и загвоздка - dbf не стандартный, поле для знаков после точки используется для расширения длины символьного поля до 700. Тут точно пользоваться ADO не получится. Или ручками или выше предложенными компонентами

[Prontit]

Сообщение от Serge_Bliznykov

1) табличка у Вас явно ЛЕВАЯ!
Вот отсюда и все проблемы!

2) что именно Вы собираетесь с этой дрянью делать?

3) TDBF пробовали? Тоже не берёт?
может быть, проще напрямую читать/писать? Если нет мемо-полей и индексных файлов это вполне возможно и даже не очень сложно!

1.) почему левый???
2.) эта дрянь у нас на предприятии активно используется
3.) Tdbf не пробовал но уверен что так же резать будет. сейчас попробую.

самый парадокс в том (парадокс не база ;]) что в ручную можно написать все 700, а программно через Delphi режет(

а как "напрямую" писать?

[Prontit]

Сообщение от alexiz

Табличка нормальная. Лично я в ней ничего левого не рассмотрел.

Записал в нее строку 400 символов в поле AD2_TXP и не чирикнула.

Использовал VKDBF.

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

кстати, работаю в RAD 2010, наверняка под него мало компонентов заточеных под DBF

[Prontit]

Сообщение от Аватар

AD2_TXP интересное описание - символьное поле с длиной 188 и двумя знаками после точки. В этом наверно и загвоздка - dbf не стандартный, поле для знаков после точки используется для расширения длины символьного поля до 700. Тут точно пользоваться ADO не получится. Или ручками или выше предложенными компонентами

у меня проблема только с одним полем, естественно с AD2_TXP. может все остальные писать через BDE, а его "вручную"...если объясните как)

[Аватар]

Устройство dbf - в начале заголовок с описанием, а дальше записи фиксированной длины и структуры. Вот и читайте как бинарный файл, используя TFileStream или FileOpen с FileRead

[Prontit]

Сообщение от Аватар

Устройство dbf - в начале заголовок с описанием, а дальше записи фиксированной длины и структуры. Вот и читайте как бинарный файл, используя TFileStream или FileOpen с FileRead

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

[Prontit]

Сообщение от alexiz

Табличка нормальная. Лично я в ней ничего левого не рассмотрел.

Записал в нее строку 400 символов в поле AD2_TXP и не чирикнула.

Использовал VKDBF.

Вы не моглибы пример скинуть, что-то у меня не получается с этим компонентом работать

var
add : TDBF;
begin
add.TableName:='C:/1.dbf';
add.Append;

что не так делаю...

[Serge_Bliznykov]

Лично я в ней ничего левого не рассмотрел.

1.) почему левый???

отвечаю на вопрос. почему левая..
потому что, в DBF можно запихнуть что-угодно. Но это будет понимать только та программа, разработчики которой и изменили DBF под свои нужды.
Можно и связи между таблицами хранить, и дополнительные типы данных, и имеющиеся расширить диапазоны, всё это абсолютно нормально. НО!
Подобные изменения приводят к отходу от стандарта. И сразу возникают проблемы со совместимостью.
Что мы, собственно, и наблюдаем в данном случае!

Справедливости ради надо сказать, что согласно википедии
DBF
уже допустимы различные значения для символьных полей:

Код 	Размер 	Тип 	Описание/Размер 	                    Используется
C 	1..n 	Char 	n ASCII символов 	                         Все
			пустые места - пробел 0x20(32)      Dct
			n = 1..64Kbt 	FS
			n = 1..32Kbt 	Fp, CL
			n = 1..254 	Все

однако, FoxPro как под DOS (FPD 2.6), так и под Windows (FPW 8.0) не позволяют работать с символьными полями длинее 254 символов.
Поэтому, думаю, что и провайдеры, построенные на основе этих движков, тоже не обеспечат доступ к подобным полям.

AD2_TXP интересное описание - символьное поле с длиной 188 и двумя знаками после точки.

нет. на самом деле всё не так!
дело в том, что там (на месте, где задаётся размерность поля) в данном случае используется ДВА байта: BC 02
та программа, что "в курсе" про большой размер поля, читает эти два байта как Word: 0x02BC = 700
те же, кто не знает (FoxPro, например) считает, что первый байт длина (0xDC = 188), а второй байт - количество десятичных цифр (что, разумеется, БРЕД!)

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

хм.. очень сильно сомневаюсь, что Вам удасться обойтись - "стандартными" средствами. И не понимаю, Ваше нежелание воспользоваться компонентом, который понимает нужную Вам структуру...
(кстати, я проверил, TDBF - НЕ понимает.. работает только со 188 символами поля)

меня проблема только с одним полем, естественно с AD2_TXP. может все остальные писать через BDE, а его "вручную"...если объясните как)

во-первых, что за склонность к некрофилии? Зачем Вам BDE ?! И что, этот труп всё ещё в составе Delphi RAD 2010 ?!! я в шоке...

во-вторых, писать поле вручную - это работать с файлом как с обычными бинарным. (ну, грубо говоря, через TFileStream). Смещения высчитывать вручную (для DBF с его простым заголовком это делается на раз-два!). Я имею опыт подобной работы с DBF файлами и мог бы помочь с написанием подобного кода!
НО!
Я бы всё таки рассматривал этот вариант как крайний метод решения проблемы!
Ибо данный способ - это всё таки костыли. Помимо неудобств, связанных с отстутствием в данном способе нормальных методов работы с датасетом (см. TDataSet ) и, как следствие, невозможности использовать DB ware компоненты! (отобразить данное поле в гриде, например), помимо крайней неэффективности в случае групповых модификаций и изменений, этот способ ещё и недопустимо использовать, если к данному файлу имеются индексные и мемо-файлы.
И плюсов у данного способа всего два:
- отсутствие зависимости от внешних компонентов, провайдеров, BDE, ADO, ODBC и т.д. и т.п.
- возможность читать любые нестандартные DBF файлы. Хоть с длиной целой части в 50 знаков, хоть с длиной символьного поля в 64 килобайта... любые извраты..

а решать - Вам...