Забрать данные из текстовой таблицы

← →
K_Dim (2002-06-14 13:23) [0]

Есть таблица в текстовом формате. Нужно забрать из неё данные. И всё вроде бы хорошо, но время от времени вываливается "Data structure error". Причём появление этой ошибки зависит только от числа строк в таблице! К примеру если принимается 87 записей - ошибка, а если там же любую строку удалить или продублировать -всё ок. Ошибка вываливается когда на последней записи таблицы делаем tblTXT.next. Кстати на попытку сделать tblTXT.last говорит, что это свойство не поддерживается.
И ещё: это происходит только на машине заказчика; у меня всё работает.

← →
-=Sergeante=- (2002-06-14 13:25) [1]

IMHO лучше руками разбирать структуру.

← →
K_dim (2002-06-14 13:53) [2]

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

← →
-=Sergeante=- (2002-06-14 19:14) [3]

С текстовыми полями не работал. Может там вкрался левый символ?
К тому же: работать с тхт как с БД - дело неблагодарное. Если требуется перегнать большой объём тхт в БД, то, как я и сказал, нужно разработать простой парсер, перегнань данные в БД, а потом уже и last и seek и проч.

← →
Desdechado (2002-06-17 16:23) [4]

может, разделитель строк кривой в конце или отсутствует?

← →
K_dim (2002-06-19 12:40) [5]

Если дело в левых символах или разделителях, то почему на моей машине всё работает и не ругается. Сбоит только у заказчика. И потом, если в заругавшемся файле продублировать или удалить ЛЮБУЮ строку - всё начинает работать. А при дублировании левые символы должны остаться. Замечено вот что: сбоит только при определённом ЧИСЛЕ СТРОК в принимаемом текстовом файле.
Понятно, что можно и ручками делать, но ведь интересно даже, отчего это так происходит. И ещё интересно не обойти, а именно побороть эту гадость. Может, кто-то в курсе, в чём тут дело.

← →
erik (2002-06-19 13:27) [6]

Попробуй прямой драйвер к TXT, например SDF.
TSdfDataSet, TFixedFormatDataSet. Или vk... посмотри на torry

← →
sniknik (2002-06-19 19:10) [7]

Обрати внимание файлы *.txt (еще с досовских времен) могут завершатся символом $1A а могут его не иметь. Не в этом ли различие?
Если на машине заказчика создается файл с этим символом то последняя строка будет пустой (даже не "" а вообще) и вывалится по ошибке. А редактор в котором вы удаляли строку его не вставляет. И работаеш ты с копиями файлов правильно? а при копировании он может отсекатся. ?возможно???
проверь.

← →
K_dim (2002-06-20 12:38) [8]

sniknik © (19.06.02 19:10)
> файлы *.txt (еще с досовских времен) могут завершатся символом > $1A а могут его не иметь. .. а при копировании он может
> отсекатся.
ОБА-НА!!
Пустая строка в конце действительно есть. Символа $1A нет. Добавляю его у себя - действительно заругалось, но не на структуру, а "TProgressBar property out of range" (у заказчика туже так ругалось, но только после того, как обругает структуру).
А при копировании файла, дублировании/удалении записей никуда этот $1A не пропадает. И ошибка не пропадает.
Короче, промах.
Не то..

← →
sniknik (2002-06-20 15:00) [9]

А пустая строка говориш есть. Насколько я понимаю таблица в текстовом формате с разделителями? Ну там пробел, запятая, точка с запятой. А какие у пустой строки разделители? Может на нее и ругается.
И потом последняя строка может быть с символами перехода на следующую $0D$0A может нет. Надо подробно разбиратся с различиями в структуре. Разные редакторы могут по разному текст сохранять. Кто тебе этот файл готовит? (не сам же такой формат базы выбрал)
Или действительно заменить компонент. Но может статся что он тебе ту же ошибку будет давать.
P.S.
на символ конца файла $1A сейчас внимания не обращают а раньше кое какой вес он имел. даже дос утилита копирования файлов имела форматы as binary/text.

← →
K_dim (2002-06-21 09:41) [10]

sniknik c (20.06.02 15:00)
Текстовый файл образуется в недрах одного из "Клиент-банков". Разделителей нету. Всё идёт сплошняком, потом режу его согласно указанной структуре.
Насчёт символов $0D$0A - очень интересно. Они там точно должны быть. Но ни в одном редакторе я не могу их увидеть. В чём их можно посмотреть?
И всё-таки. Ну пускай где-то в конце закрался глюкавый символ. Я вырезаю, например, 3-ю строку. Он что, пропадает? А потом вставляю эту строку после 10й. И он опять появляется? Не верю.
НУ В ЧЁМ ЖЕ ПРИЧИНА?

← →
sniknik (2002-06-21 10:23) [11]

Посмотреть можно hiew - есть такая смотрелка/битовый редактор или просто в досовском нортоне просмотр F3 - дальше коды F4.

$0D$0A - это символы завершающие каждую строку само собой у последней их может не быть. Зависит от редактора каким сохраняеш они иногда предварительно форматируют текст (пример Паскаль обрезает все пробелы завершающие строки)

Проверь так сделай изменение в тексте а после убери его (не отменой Cntr+Z а тоже редактированием) чтобы в редакторе поднять флаг изменений. если глюк от этого то после сохранения он должен убратся хотя реальных изменений нет и тогда смотри чем файлы отличаются.

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

Забрать данные из текстовой таблицы Найти похожие ветки