Форум » [x]Harbour » Помогите открыть DBF-файл из Киева.... » Ответить

Помогите открыть DBF-файл из Киева....

Andrey: Всем привет. Прислали мне тут DBF-файл, а современные "смотрелки" вылетают.... http://files.mail.ru/WBLOJS DBedit Pavel Tsarenko - предлагает изменить заголовок и обрезает базу. Открывает только старый DBU на Клипере. Что посоветуете, как работать с такими файлами... У меня много их потом будет...

Ответов - 25, стр: 1 2 All

Dima: Плагин для Far , LookDBF нормально открыл. Harbour и Xharbour cчитают что файл пуст. Сами файлики тебе слали в архиве или в чистом виде ? Помнится был глюк у Тhe Bat. Если dbf-ик слать в чистом виде то при сохранении туда дописывалась какая та дрянь PS Clipper так же нормально открыл файл ЗЫ1 Excel открыл норм ;)

Andrey: Dima пишет: Помнится был глюк у Тhe Bat. Если dbf-ик слать в чистом виде то при сохранении туда дописывалась какая та дрянь Спасибо БОЛЬШОЕ Дима, а то я думал что мне труба... Это оказывается The BAT! глючит...

santy: В файле повторяются названия полей (DOPP_2 и т.д.). Открылb только DBF Manager и плагин для Фара.


Andrey: santy пишет: В файле повторяются названия полей (DOPP_2 и т.д.). Это ошибка программеров или The Bat! "постарался" ? И каким языком можно продублировать поля в БД ?

Сыроежка: Не открывайте подозрительные посылки. Позвоните лучше в милицию!

AlexMyr: Сыроежка, во флейме анекдоты рассказывайте!

Сыроежка: Может быть этот файл сформирован СУБД которая разрешает в качестве полей указывать массивы. И, возможно, именно поэтому имена дублируются. Если их характеристики одинаковы (число знаков в поле и количество после запятой), то скорей всего это именно массив. Clipper, если имеется в виду DBU, открывает файл наверное потому, что он не проверяет дублирование имен полей. Возможно вам придется отредактировать заголовок, изменив имена дублирующихся полей.

santy: не думаю что это The bat , в версии 3 х такого не наблюдал. В принципе можна протестить. Скажите пусть заархивируют и пришлют вам ещё раз. Сравните структуру.

Andrey: santy пишет: не думаю что это The bat Спасибо БОЛЬШОЕ. Так и поступлю...

santy: Ещё этот файл открывает внутренний редактор dbf xedit oт Xailer . При просмотре структури видно что поля одинаковые , разница только в длине поля типа С.

Сыроежка: Может быть проще у них, то есть в Киеве, спросить, какой СУБД сформирован файл, и разрешается ли запись массива полей. Еще такая делитантская мысль пришла. Не может ли быть так, что этот файл подготовлен в 1С? Как иззвестно, если я не ошибаюсь, они в 8-ой версии используют собственную СУБД. Может быть при выгрузке в формат DBF, их пррграмма просто вставила имена, которые соответствуют имени одному агрегированному полю исходной СУБД. Просто сделала это автоматически.

Andrey: Сыроежка пишет: Может быть проще у них, то есть в Киеве, спросить, какой СУБД сформирован файл, и разрешается ли запись массива полей. Это сложно очень ! Из Москвы до Киева звонить и узнавать кто этим там занимается....

Сыроежка: А по электронной почте?

Dima: Andrey Похоже не в почтовой проге дело ;) На эти грабли уже натыкались в 2010 и структура файла такая же. Смотрим тут

Pasha: Клиппер и остальные средства работы с форматом dbf поддерживают символьные поля размером до 256 байт, а харбор - до 64к. Для этого в заголовке для указания размера такого поля используется 2 байта - байт длины и байт к-ва десятичных знаков. В "киевском" файле в байте для десятичных знаков ошибочно указано 2, хотя должно быть 0. Вот харбор и вычисляет длину такого поля более 256 байт. Если открыть файл через dbedit, не исправляя заголовок, и посмотреть его структуру, то символьные поля размером более 500 байт - как раз они и есть. В результате харбор неверно определяет общий размер записи, и отсюда все дальнейшие беды. Насколько я знаю, excel как раз может формировать такие битые файлы.

evsob: Pasha пишет: Клиппер и остальные средства работы с форматом dbf поддерживают символьные поля размером до 256 байт Вообще то в Клиппер 5.01, согласно официальной документации от Nantucket, максимальная длина символьного поля 64k. Для этого в заголовке для указания размера такого поля используется 2 байта - байт длины и байт к-ва десятичных знаков.

Pasha: evsob пишет: Вообще то в Клиппер 5.01, согласно официальной документации от Nantucket, максимальная длина символьного поля 64k. Это для memo-поля. А для символьного поля максимальная длина 256 байт, так как в заголовке dbf для длины поля используется 1 байт. В структуре заголовка поля есть еще байт для определения числа десятичных знаков числового поля. Для символьного поля он не задействован. А в харборе этот байт как раз используется для задания размера символьного поля до 64к.

evsob: Pasha пишет: Это для memo-поля. А для символьного поля максимальная длина 256 байт Во-первых передо мной официальная документация. Во-вторых пользовался сам в базах такими полями. И в-третьих дбушука (русская) от него читает прекрасно эти файлы.

Pasha: evsob пишет: Во-первых передо мной официальная документация. Во-вторых пользовался сам в базах такими полями. И в-третьих дбушука (русская) от него читает прекрасно эти файлы. Ну дайте ссылку на доку. Тест для 5.01: dbCreate('test', {{'F1', 'C', 300, 0}}) В результате создается файл с полем f1 размерностью 44 символа, т.е. остаток от деления на 256. Так как и должно быть. Не надо выдумывать того, чего нет.

Pasha: Я оказался неправ, давно не работаю с клиппером. Действительно, в клиппере поддерживается символьные поля до 64к А проблема в исходном киевском файле заключается в том, что размер записи в заголовке (2641 байт) не соответствует сумме длин полей (11345 байт). Это произошло вследствие того, что для клиппера (и харбора) к-во десятичных знаков для поля С величина значащая, а для прочих dbf-ридеров - незначащая. А для некоторых полей это значение оказалось заполненным.

Сыроежка: Пока товарищ отсутствует, то я постараюсь за него ответить. Дело в том, что сам программист должен задать значения для этих полей. Если мне память не изменяет, то размер поля для задания длины составляет всего лишь байт. Поэтому когда указывается значение больше 255, то очевидно в поле занесется лишь остаток по модулю 256. Что касается документации, то, например, в книге "Руководствоо по применению Clipper 5.0 на ПЭВМ" написано следующее (4-50). "Символьные поля длиной свыше 255 символов. Существует два метода создания символьного поля длиной более 255 знаков: Укажите длину поля, используя поля Field_len и Field_dec согласно следующей формулировке: FIELD->Field_len := <nFieldLength> / 256 FIELD->Field_dec := INT( <nFieldLength> / 256 ) Модифицируйте сттруктуру, изменив длину Field_len до 5, а затем установите действительную длину поля. Это можно выполнить в DBU.EXE"

evsob: Pasha пишет: Ну дайте ссылку на доку. Тест для 5.01: dbCreate('test', {{'F1', 'C', 300, 0}}) В результате создается файл с полем f1 размерностью 44 символа, т.е. остаток от деления на 256. Так как и должно быть. Не надо выдумывать того, чего нет. Официальная документация передо мной не на ресурсе в интернете, а в виде банальных книг (на русском!) прилагаемых к лицензионному продукту. Поэтому ссылку на нее дать не могу. А вот где там написано: В описании к команде COPY STRUCTURE EXTENDED есть примечание. Если хотите выложу скан со страницы. И вообще привык говорить правду и подкреплять свои слова документами. Об этом в документации еще упаменается у команд COPY STRUCTURE, CREATE, CREATE FROM, FIELD(), TYPE()

evsob: Andrey пишет: Всем привет. Прислали мне тут DBF-файл, а современные "смотрелки" вылетают.... http://files.mail.ru/WBLOJS DBedit Pavel Tsarenko - предлагает изменить заголовок и обрезает базу. Открывает только старый DBU на Клипере. Что посоветуете, как работать с такими файлами... У меня много их потом будет... Что с ним делать хочешь? В Клиппере подобный случай обрабатывается используя номера полей. Выглядит это примерно так: //Prog Kiev Пример в Клиппер [pre2]USE YRP_040512_095354 nField :=FCOUNT() aValField[nField] DO WHILE !EOF() FOR m=1 TO nField //Обработка записи aValField[m] := FIELDGET(m) //Обаботка поля END SKIP ENDDO [/pre2]

Andrey: evsob пишет: Что с ним делать хочешь? Мне нужно открывать подобные "убитые" файлы в своей программе и перебрасывать записи в свою базу. Таких файлов будет много каждый месяц. evsob пишет: В Клиппере подобный случай обрабатывается используя номера полей. А если в этих файлах сменят структуру базы ? Или юзера запишут вообще другой DBF... Как тогда отловить такой момент ?

fil: а чего, fieldname(nn) не работает ?



полная версия страницы