Форум » [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-ридеров - незначащая. А для некоторых полей это значение оказалось заполненным.



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