Sdbf 4.5 (DBF-редактор с поддержкой SQL) #707331

Sdbf 4.5 Улучшен SQL-редактор: 1. добавлено цветовое оформление полей в зависимости от типа данных колонки; 2. добавлено комбинацию клавиш Alt+→ для автоподбора ширины полей. Поддержите проект:

...комбинацию клавиш Alt+(стрелка вправо)...

хохлы мегаактивны :)

молодцы, красивенько.

С виду ниче так. Мне кажется вы опоздали лет на 10 как минимум.

автору хочется в чем-то проявить себя, почему бы нет?

Да, если бы у меня в руках был такой инструмент ещё лет 5 назад, я бы был счастлив. Хотя и сейчас многие люди говорят «спасибо», так как DBF живёт во многих госструктурах и др. организациях. Сейчас, например, DBF широко используется в геоинформационных системах, хотя это отдельная история.

В мою семерошную бытность он бы тоже пригодился. Но тогда лучшим был DBF Navigator

DBF Navigator и сейчас лучший. По крайней мере буквально с месяц назад у меня навигатор открыл полутрагигабайтный DBF с текстовыми полями длинной порядка 900 символов, а SBDF падал при открытии. Реструктуризировать не смог ни кто, кроме FoxPro ;)

не лучший, на больших дбф-ках он просто не откроется.

Поправьте меня, если я не прав, но насколько я знаю для DBase любых версий и Visual FoxPro максимальная длина строки (тип C) 254 символа. Все остальные случаи – это отклонение от стандарта или испорченные заголовки файлов.

Можно мне посомтреть на этот файл с несколькими сроками данных? Хочу потестировать.

Файл представляет собой табличную часть документа, полученную штатными средствами 1С. Так что в рамках этого форума, это стандартный DBF. Дать уже не могу. Потому что файл уже реструктуризирован, длины полей укорочены. Теперь он открывается sDBF. Правда это занимает несколько минут. Сейчас размер файла 640 мегабайт, порядка 260000 записей. В нём одно строковое поле длиной 999 символов, парочка 200-300 символов, остальное более вменяемых размеров. До реструктуризации было три или четыре поля длиной 999 символов и размер порядка 1.6 гигабайта.

Не забываем, что 1С позволяет хранить в dbf-файле строки длинной до 999 символов, и прекрасно с ними работает. С помощью такого "справочника" можно создать некоторый аналог blob-полей, который не разделяет с другими объектами своё хранилище.

Реструктуризация прошла без потерь данных? Отсеялись только пробелы? Интересно, как FoxPro мог оставить такие длинные поля после реструктуризации, если это конечно не МЕМО-поля?

1C использует для байта длины для char (то есть длина и количество десятичных разрядов).

00000000A0: 56 45 52 53 54 41 4D 50 ? 00 00 00 43 00 00 00 00  VERSTAMP   C 00000000B0: 06 00 00 00 00 00 00 00 ? 00 00 00 00 00 00 00 00  ? 00000000C0: 53 50 33 39 00 00 00 00 ? 00 00 00 43 00 00 00 00  SP39       C 00000000D0: E7 03 00 00 00 00 00 00 ? 00 00 00 00 00 00 00 00  c? 00000000E0: 53 50 34 30 00 00 00 00 ? 00 00 00 43 00 00 00 00  SP40       C 00000000F0: E7 03 00 00 00 00 00 00 ? 00 00 00 00 00 00 00 00  c? 0000000100: 0D 1A                   ?                          ?? А вот DD: #==TABLE no 12     : Справочник Длинный # Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable   T=SC37    |Справочник Длинный            |A          |SC37       |1         #-----Fields------- # Name      |Descr               |Type|Length|Precision F=ID        |ID object           |C   |9     |0         F=CODE      |object code         |C   |5     |0         F=DESCR     |object description  |C   |25    |0         F=ISMARK    |Flag Object is Marke|C   |1     |0         F=VERSTAMP  |Version stamp       |C   |6     |0         F=SP39      |(P)ДлиннаяСтрока    |C   |999   |0         F=SP40      |(P)ЕщёСтрока        |C   |999   |0         #----Indexes------ # Name     |Descr         |Unique|Indexed fields                                              |DBName     I=IDD      |of ID         |0     |ID                                                          |IDD         I=CODE     |of CODE       |0     |CODE(UPPER)                                                 |CODE       I=DESCR    |of DESCR      |0     |DESCR(UPPER)                                                |DESCR       Всё штатно и красиво.

Если почитать формат файла: То будет понятно, что 1С просто плевала на то, что там написано.

И я о том же.

Интересно было бы посмотреть на полное описания формата DBF от 1C.

Не забываем, что и индексы там немного по-другому работают - так что для 1С нужен свой редактор. Хотя, если посмотреть описание драйвера CodeBase, то там, наверное, про всё это сказано. P.S. отсутствие memo-полей в семёрке - это самый большой и жирный минус.

Вот здесь сказано: 33     0x21     1     Полная длина поля 34     0x22     1     Число десятичных разрядов; для типа C - второй байт длины поля То есть, это не изобретение 1С.

+ А, собственно, знакомая картинка - я по ней парсер dbf-файлов для их восстановления писал.

Кстати, заголовок 1С-файла говорит, что это стандартный dbf-файл.

СПАСИБО!

А вот и описание cdx-файла:

Что именно интересно и что непонятно ? Там мелкие отличия в сортировке и заголовке файла Но имхо поезд ушел лет 10 назад

Не, ну кто-то на этом паровозе ещё ездит, и при должной доработке он "файловый экспресс" от 1С8 догонит, и "не сойдёт с рельсов" при первом выключении компьютера.

И что ? FoxPro вообще рвал всех и ничего не требовал. Но умер, а стоимость разработки там были млрд не рублей. Формат практически тот же

Интересно, почему "... навигатор открыл полутрагигабайтный DBF с текстовыми полями длинной порядка 900 символов, а SBDF падал при открытии...", а после реструктуризации когда стало "...в нём одно строковое поле длиной 999 символов, парочка 200-300 символов, остальное более вменяемых размеров..." файл без проблем открылся?

Разные технологии открытия FoxPro поддерживает оба варианта ("SQL" и послед чтение) . В одном из вариантов он только читает заголовки и двигается по "листьям" CDX, не засасывая файл целиком При отображении в таблице считывает только следующие данные По сути мог бы 10 ГБ открывать

То есть Sdbf-у просто не хватило оперативки при попытке полностью загрузить файл?

Видимо - да. dbf-файл предполагался для чтения по записям, из-за чего размер записи должен был быть меньше 64К (если кто-то помнит, с чем это связано).

Реструктуризацию для надёжности делал не фокспро, а "штатными" средствами 1С. :) Распределенка, центральная SQL. Грохнул табличную часть на ПБ DBF и устроил полную миграцию этого вида документов. После реструктуризации файл стал открываться sDBF, только медленно и печально. А на старом файле, размером 1.6 гига, на сколько помнится, при открытии вылезали ошибка нехватки памяти.

При наличии 2-х гиг оперативки файл в 1.6 гиг легко бы открылся. Так уж устроен Sdbf.

Факт есть факт. Не открывался. Физической памяти 4 гига.

Обязательно проверю. Спасибо.

Может, кто ещё пробовал открывать файлы размером больше 1.5 Гб с помощью Sdbf. Поделитесь результатами.

Дело, наверное, было не в размере DBFника, а в размере записи или индексе. Нашел у себя DBFник размером 1.5 гига. Открывался долго, потому что копировал во временный файл. Но открылся. Структура этого DBFника проще и меньше. В табличной части документа один реквизит, строка.

Изначально временный (.tmp) файл было решено создавать на случай «Ой … не то стёр и копии нет». Так как изменения не кэшируются, а сразу применяются.  Это большой минус, но пока так. Нужно будет сделать  гибкую настройку программы конкретно под каждого пользователя, но это зависит от приоритетов и поддержки проекта. Пока всё на добровольных началах.

Может быть создавать временный файл не при каждом открытии, а при попытке редактирования? А то тормозит, тормозит при открытии, а редактировать и не надо, только посмотреть. А то бывают еще ситуации, когда с какого-нибудь примапленного инет-хранилища файл посмотреть надо.

У меня в редакторе диска во временные файлы писались только изменённые сектора (то есть то, что было изменено). Потом, когда делался "COMMIT" это всё писалось в основной файл, а так - он рассматривался ReadOnly и не поднимался весь в память.

1.8 нормально открывает, в отличие от дбфнафигатрока, который не алё при этом..

Вот этот DBF , штатно сделанный в 1С, открывается нормально. За 3.5 минуты на моём пожилом ноуте. А вот реструктуризацию сделать нельзя, не принимает строки такой длины.

Не удалось скачать файл по ссылке. Пишет: "OneDrive не удалось проверить dt12.dbf.7z на вирусы." и отказывается скачивать.

На счёт реструктуризации, то в текущей версии действительно стоит ограничение на длину строки в 254 символа - исправлю в след. версии.

у меня другой вопрос: пишет ли 1С в 1-3 байты заголовка DBF дату последнего обновления данных, или там остаётся неизменной дата создания файла (последней модификации структуры)? нет возможности проверить

и ещё, отсчет года начинается с 1900 года (см. 1 байт заголовка) или с 2000?

1) Почему при открытии диалога sql запроса таблица закрывается? Что, нужно держать в голове структуру таблицы или сначала запрос писать на бумажке? 2) "Однооконность" резко сокращает применимость утилиты. Как минимум нужно иметь возможность держать открытыми несколько таблиц Ну а в целом "не взлетит", опоздал на 10 лет.

Вот зараза! Держи пожатый зипом Его отдаёт. Попробовал добавить данных. Изменились только 4-6 байты файла. 0000000000: 03 72 05 07 D8 AC 07 00 ? 21 01 E3 0E 00 00 00 00 0000000010: 00 00 00 00 00 00 00 00 ? 00 00 00 00 01 00 00 00 0000000020: 49 44 44 4F 43 00 00 00 ? 00 00 00 43 00 00 00 00 0000000030: 09 00 00 00 00 00 00 00 ? 00 00 00 00 00 00 00 00 Зайти на инфостарт и поищи там "DBF" в разработках. Дофига. Свеженького. Буквально вчера пробежала какая-то выгрузка в Сбербанк. Так что, никакого "опоздания" пока не наблюдается.

СПАСИБО! Интересно, что такой подход к записи даты модификации (структуры, а не данных!) предполагает последнюю возможную дату - 1900+256=2156 год, так как 0x72=114 (см. первый байт). Опять же, в описании DBF формата сказано, что в первый байт дожлжен быть записан год в формате YY, то есть не 0x72=114, а 0x20=14. Вот и думай, как правильно год записывать.

Опечатка 0x0E=14.