конвертация баз FoxPro в dBASE IV

← →
SCORPION ZP (2003-07-30 19:20) [0]

Кто нибудь подскажет есть ли способ переконвертировать базы
FoxPro в dBASE(включая memo-и индексные-файлы)? Баз несколько тыс., поэтому способ импорта в Excel, а затем сохранить как
dBASE, не подходит. Желательно чтобы это могло работать в цикле.

← →
Anatoly Podgoretsky (2003-07-30 21:25) [1]

А сколько в каждой базе таблиц?
Могут возникнуть проблемы если кодировка 1251 (dBase) не поддерживает, кроме того индексы могут не позволить преобразование.

← →
SCORPION ZP (2003-07-31 09:53) [2]

Anatoly Podgoretsky
1.Одна.Скажем так по 3000 dbf,cdx и fpt. FoxPro под DOS(866).
Но кодировка пока на втором плане - главное перевести на dBASE, Delphi нет полной поддержки фокса.
2.
> Могут возникнуть проблемы...

> ...могут не позволить преобразование...

Как это сделать или с пом. чего? А я проверю "могут" или нет.

← →
SCORPION ZP (2003-07-31 20:20) [3]

Ребятя очень нужно! Кому не лень дать хоть ссылку по сабжу!

← →
Dred2k (2003-07-31 21:44) [4]

Ну что ж, задача у тебя довольно сложная.
Могу посоветовать динамическое создание таблиц.

1. Для каждой исходной таблицы всех твоиз баз (в цикле):
1-1. Создаешь экземпляр TTable (TableType := ttDBase).
1-2. Открываешь исходную, делаешь ей FieldDefs.Update, IndexDefs.Update.
1-3. Для созданного экземпляра делаешь FieldDefs.Assign(исходная.FieldDefs), IndexDefs.Assign(исходная.IndexDefs).
1-4. Для экземляра выставляешь полный путь (DatabaseName), TableName (имя файла, расширение не нужно, можно присвоить от исходной, если все обрабатываемые файлы, читай - таблицы, имеют разные имена или каталоги) и TableLevel (0 - берется из настроек BDE для DBase, для DBaseIV не знаю, т.к. юзаю Paradox).
1-5. Создаешь экземпляр как физ. таблицу по CreateTable.
1-6. Заливаешь данные из исходной в экземпляр любым способом (на уровне TTable, о файле не заботься - он на месте).
1-7. Если есть еще исходные, возврат на 1-1.
2. Проверяешь органолептическими средствами все таблицы всех экземпряров (должны совпасть с исходными). ;))

При всем при этом могут возникнуть многие проблемы, как то: кодировки ( > Anatoly Podgoretsky © (30.07.03 21:25)
тебя об этом уже предупреждал, битые исходные таблицы, и т.д. и т.п. - особенности движка DBase-Foxpro в BDE мне не ведомы, почему - сказал выше ;) )

Делай все аккуратно и не скупись на тесты. Больше тестов - ближе победа! Успехов.

← →
SCORPION ZP (2003-08-01 09:53) [5]

Dred2k
Спасибо за советы. Буду ломать эту проблему и если ничего не
выйдет или что будет не так обращусь к вам за помощью.

← →
KSergey (2003-08-01 10:19) [6]

А могет взять сторонний компонент для доступа к DBF будет проще?
Например, Halcyon работают с фоксовскими индексами и мемо-полями вполне успешно...
Тем более, что есть подозрение, что и с поддержкой DBase-файлов со стороны BDE (о нем речь?) могут возникнуть трудности...

← →
Anatoly Podgoretsky (2003-08-01 15:51) [7]

Dred2k © (31.07.03 21:44)
Проблемы с кодировкой не будет, он все таки указал, надеюсь, что он это указал про Table Language, а не про конкретные буковки в табличках. Индексы особая вещь, тут можно получить по самые помидоры. Но с другой стороны в новых таблицах не обязательно точно такие же индексы, а отключить индексы от исходной таблицы не проблема.
Но то решение, о котором ты говоришь, это копирование данных, до нехого каждый пацак догадается. А вот конвертация средствами БДЕ это проблематично, средствами FoxPro в одном направлении, просто от отключает индексы и мемо поля и создает их копию и им не к чему было делать это в пользу конкурентов (в тот момент dBase IV они и так отставали).

KSergey © (01.08.03 10:19)
с поддержкой DBase-файлов со стороны BDE просто нет проблем, он заточен, а вот поддержкой FoxPro одназно есть.

← →
SCORPION ZP (2003-08-01 16:37) [8]

Поэтому и стремлюсь к dBASE(из-за его полной поддержки в Delphi)
Думаю, что проблема рештся через Microsoft.Jet.OLEDB.4.0,ADOConnection и ADOCommand.

← →
Dred2k (2003-08-01 16:57) [9]

> Anatoly Podgoretsky © (01.08.03 15:51)

Чем, на твой взгляд, отличается конвертация от копирования?
Использованием dbiDoRestructure и манипуляциями с TblDesc, IdxDesc и т.п. вместо TTable? Происходить при этом будет фактически то же самое, только через более низкий уровень вызовов. То, что это решение будет принципиально лучше - сомневаюсь. На уровне TTable обеспечена достаточная поддержка всех необходимых фич, опять же средствами BDE. Да и потом - чем проще, тем надежнее (критерии простоты, конечно, разные бывают).
Вот насчет сохранения индексов (заметь - в вопросе он об этом говорит), типов данных - проблемы, наверное, могут быть. Во всем копаться надо и проверять, по-любому.

← →
Anatoly Podgoretsky (2003-08-01 17:05) [10]

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

← →
Dred2k (2003-08-01 17:06) [11]

> SCORPION ZP © (01.08.03 16:37)

Ну, коли так, то почему не парадокс? Он в BDE тоже хорошо поддержан, кроме того, есть положительные различия с dbaseIV...

← →
Dred2k (2003-08-01 17:13) [12]

> Anatoly Podgoretsky © (01.08.03 17:05)

> В первом случае копия не создается, а преобразовывается
> структура, если необходимо.

Если первый случай подразумевает dbiDoRestructure, то манипуляции производятся через временную таблицу (по дефорту - resttemp.*). Возможно, есть ситуации, когда никакой перекачки не происходит. Но при изменении драйвера этого избежать просто невозможно.

> но иногда надо ручками затачивать

Абсолютно согласен. Но по существу вопроса предлагаю для начала проверить - требуется такая заточка или можно обойтись без нее.

← →
Anatoly Podgoretsky (2003-08-02 12:24) [13]

Dred2k © (01.08.03 17:13)
Нет использование временных, файлов, переменных и прочего это совсем другое, это дело конкретной программы, но в случае конвертирования например в FoxPro таблицы просто происходит создания новых индексных и мемо файлов, сама таблица даже не затрагивается. Копирование таблиц в моем толковании, это когда я сам создам новую таблицу, перекопирую в нее данные и построю индексы, это путь самый гибкий, хоть и более сложный. Процесс можно автоиматизировать, что бы его можно было выполнять на неизвестных заранее таблицах, вплоть до воссоздания структуры баз, если они посторены в иерархию.

А что можно сказать насчет потребуется заточка или нет, если автор предпочитает играть в молчанку, не выдавая никакой конкретной информации, да просто он и ответов конкретных не получит, только точно также вокруг и около, ну это его проблемы, видимо оно ему нужно :-)

Dred2k © (01.08.03 17:06)
Положительных отличий чрезвычайно мало, отричательных гораздо больше, но правда почему бы и нет, хотя полная конвертация почти невозможно, например из за отсутствия подлинных BCD полей, индексов по выражению и много другого. Я даже не смогу с первого раза сказать, чем таким особым он отличается от dBase, естественно последних версий.

← →
SCORPION ZP (2003-08-02 15:10) [14]

ADOConnection1.Connected=False
ADOConnection1.ConnectionStrng="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=D:\_TEST\;Extended Properties=dBase IV;Persist Security Info=False"
ADOConnection1.LoginPrompt=False
ADOConnection1.Provider="Microsoft.Jet.OLEDB.4.0"

ADOCommand1.CommandText="SELECT * INTO Test FROM 31842468"
ADOCommand1.Connection=ADOConnection1
ADOCommand1.ConnectionStrng=
ADOCommand1.Parameters= по Default

TForm1.Button1Click= ADOCommand1.Execute;

И база Foxa превращается в dBASE

← →
sniknik (2003-08-02 15:35) [15]

SCORPION ZP © (02.08.03 15:10)
ну не всегда. нет универсальных решений. (уже говорил)

здесь срабатывает только потому что первые версии Jet-а поддерживали, а значит и продолжают (обратная совместимость), foxpro до 3.0. а что будет если встретится более старшая версия? или с расширенным мемо? (у фокса в мемо всегда было больше возможностей) сможет перевести в ограниченный формат мемо dBase? и т.д.
думаю ответы очевидны.

← →
SCORPION ZP (2003-08-02 17:31) [16]

sniknik
Согласен, что с FPT могут быть проблемы...
Проверю все базы на предмет перевода в dBase и лично тебе напишу
все ли перешли или нет. Сейчас аврал на работе и пока я занят.
Кстати, а как программно изменить размер поля в уже существующей таблице dBASE III?
гончий отзовись! Как там "DbChk" это сделать??????

← →
Dred2k (2003-08-03 18:34) [17]

> Anatoly Podgoretsky © (02.08.03 12:24)

> Нет использование временных, файлов, переменных и прочего это совсем другое, это дело конкретной программы

Использование временных файлов осуществляет самое нативное средство конвертации в BDE - dbiDoRestructure.

> но в случае конвертирования например в FoxPro таблицы просто происходит создания новых индексных и мемо файлов, сама таблица даже не затрагивается

Вполне возможно. Я с ними не работал, особенностей не знаю. В условиях BDE предположу, что схема будет одинаковой для всех драйверов.

> Копирование таблиц в моем толковании, это когда я сам создам новую таблицу, перекопирую в нее данные и построю индексы, это путь самый гибкий, хоть и более сложный.

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

> если они посторены в иерархию

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

> видимо оно ему нужно :-)

Он сказал, что сильно занят ( > SCORPION ZP © (02.08.03 17:31)). Решение, судя по всему, уже выбрал. ;)

> Положительных отличий чрезвычайно мало, отричательных гораздо больше

Ну, я бы так не сказал. Из всех отрицательных отличий мне видится только проблема с поддержкой, выраженная в падении индексов и т.п. Но это решается на этапе реализации, простыми и довольно тривиальными способами. Разумеется, это не снимает ответственности с разработчиков движка... ;)

По-моему, автор вопроса ищет дешивизны реализации. Что, собственно, в определенной степени не плохо.
Вот расскажет ли он о своем решении? Это еще вопрос... ;)

← →
Anatoly Podgoretsky (2003-08-03 19:26) [18]

Я не про надежность, это совсем другое дело, я именно про возможности, типы полей,индексы и прочее.

← →
Dred2k (2003-08-03 19:55) [19]

> Anatoly Podgoretsky © (03.08.03 19:26)

Если у Fox-Dbase такие проблемы при преобразовании, тогда я "ой". Но сомневаюсь, что в BDE это многозначность. Допускаю, что ты имеешь в виду и сторонние методы.

Но я говорю именно про BDE, которая имеет совершенно конкретный взгляд на все особенности. Нужно лишь поробовать и это выяснить. Вот будет ли это делать автор? Он на ADO давно смотрит (может, и с самого начала - жаль, что на форуме все воросы зачастую не блещут исчерпывающей конкретностью)...
;)

← →
Dred2k (2003-08-03 19:57) [20]

> Anatoly Podgoretsky © (03.08.03 19:26)

Возможно, при ответе я не совсем четко понял тему твоего поста.
;)
Ты про Paradox?

← →
Anatoly Podgoretsky (2003-08-03 20:47) [21]

Да про него, про его достоинства, в смысле типов

← →
Dred2k (2003-08-03 21:16) [22]

Тогда в чем конкретно ты видишь его (парадокса) недостатки?
Дело в том, что судить о деталях dBase платформы мне сложно без предварительного изучения. Когда я говорил о плюсах парадокса, имел в виду достаточно завершенный набор типов и опять же вполне достаточную концепцию ключей и индексов.

← →
Anatoly Podgoretsky (2003-08-03 21:51) [23]

Набор типов близок, но не в пользу Парадокс, отсутствуют подлинные BCD типы

← →
Dred2k (2003-08-03 22:01) [24]

> Anatoly Podgoretsky © (03.08.03 21:51)

Снова вынужден сказать "BCD не юзал".
Разумеется, на этом аргументированый спор в соответствующем направлении завершается. ;)
Мне вполне хватает Number, хотя
Note: Although BCD fields can handle larger numbers, you can only enter a number with 15 significant digits or less into a BCD field.
вводит некоторые недвусмысленные ограничения. В Dbase (...) этого нет?

← →
sniknik (2003-08-04 01:16) [25]

> Снова вынужден сказать "BCD не юзал".
> Разумеется, на этом аргументированый спор в соответствующем направлении завершается. ;)
нехватает аргументов сходи на сайт к Anatoly Podgoretsky там инфы море по этому вопросу.

> ...15 significant digits or less into a BCD field.
> вводит некоторые недвусмысленные ограничения. В Dbase (...) этого нет?
у dBase есть BCD поля (чего еще?), не путай формат/базу с представлением/реализацией в дельфях (тем более их может быть не одно).
и дочитывай хелп до конца раз уж начал.
The IDE uses two different field types for representing BCD fields: TBCDField and TFMTBCDField. TBCDField uses the Currency (Delphi) or System::Currency (C++) type to manipulate BCD values. This is faster than storing and manipulating the value using a true BCD type, but limits the precision of the BCD values it can support to 4 decimal places and 20 significant digits. (20 знаков - 4 после точки - 1 сама точка, вот твои 15)

TBCDField converts the data from a BCD value to a Currency value when it fetches the data from the database table, and converts it from a Currency value to a binary-coded decimal value when it posts the data. If the underlying database table contains a value that requires greater precision, TBCDField raises an exception. If your application requires BCD values with more than 4 decimal places or 20 significant digits, you should use TFMTBCDField instead. TFMTBCDField is a true BCD, with the precision of the binary-coded decimal type (TBCD) but with somewhat slower performance. (а вот тебе истинное, хотя и более медленное, используй, не хочу)

← →
Dred2k (2003-08-04 10:06) [26]

> sniknik © (04.08.03 01:16)

Ты аккуратен и старателен.
Большое спасибо за науку и цитаты.
Только вот ни аргументы, ни инфа по BCD мне не нужна. Я сразу об этом сказал. А принципом хелп-на-хелп балуюсь редко. Вот сейчас - нет, к примеру.
;)

← →
Anatoly Podgoretsky (2003-08-04 13:41) [27]

Dred2k © (03.08.03 22:01)
Это не страшно, мало кто работал с двумя форматами и тем более разбирался, как оно устроено.
В любом случае у нас огорчение, хоть в dBase и есть подлинные BCD поля, но зато в самой Дельфи отсутствует их нормальнаял поддержеа, насколько TFMTBCDField is a true BCD, это соответсвует истине сказать трудно, поскольку это начинается с Д6, в Д5 нет, но смущает следующее TBCDField converts the data from a BCD value to a Currency value, этим как бы сразу накладывается ограничение 20.4
Но мы рассматривали не реализацию в Дельфи, а поля в базе, вот Парадокс за исключением Currency/BCD ни чего другого не имеет, что очень огорчительно. dBase же наряду с остальными типами Парадокса изначально поддерживает и true BCD, например можно указать тип поля N10.7, а не N10 в Парадоксе и оно будет храниться в таблице именно как 10.7.
Вообще с true BCD полный бардак, реально они были полностью реализованы только в dBase IV, а после передода его на BDE это было потеряно, их стали просто эмулировать на основе других типов, тоже касается и FoxPro в них никогда не было полной поддержки.

← →
Dred2k (2003-08-05 09:59) [28]

> Anatoly Podgoretsky © (04.08.03 13:41)

Да уж, с BCD ситуация нехорошая получается. До сих пор обхожусь number-ом. Кроме того, в парадокс7 есть целочисленный 32-битный тип, который очень полезен для суррогатных ключей и вообще хранения целых (есть еще short). Вот то, что _специализированных_ целых нет в dBaseIV - это минус, на мой взгляд. Т.к. предполагаю, что любые операции со специализированном типом быстрее, чем с универсальным, определяющимся параметрами. Ну, еще не хватает Time (хотя можно хранить и в number, но менее удобно). Про autoincrement в данном контексте говорить не буду - вещь может и неплохая, но реализована в BDE кривовато, я этот тип не использую.

← →
Anatoly Podgoretsky (2003-08-05 10:22) [29]

Ну ты посмотри Парадокс версии 3, или уж тогда смотри dBase версии не ниже 7. Там есть то что ты хочешь, то есть тип LONG, Integer и другие, включая autoincrement и несколько типов индесксов, простые, уникальные, сжатые, по выражениям.
Тип Time всегда можно хранить в timestamp или character 8.

← →
Dred2k (2003-08-05 11:33) [30]

Смотрел с помощью DBD все предлагаемые версии, long-а не увидел. Хотя в хелпе о нем для dbase говорится (трансляция логических типов для разных дров). Microsoft dBase driver поразил богатством odbc-шных типов ;)

← →
Anatoly Podgoretsky (2003-08-05 12:57) [31]

Dred2k © (05.08.03 11:33)
DBD не пригоден, поскольку последняя его версия 1997 года, тогда dBase VII не было. Они поставили на DBD крест, что бы не создавать конкуренции для Парадокс. А потом и Парадокс продали и после и dBase, хотели и Интербейс прикрыть.

конвертация баз FoxPro в dBASE IV Найти похожие ветки