Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: 1 2 >
SCORPION ZP © (2003-07-30 19:20:00)

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

Anatoly Podgoretsky (2003-08-05 12:57:00) [1]

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

Dred2k (2003-08-05 11:33:00) [2]

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

Anatoly Podgoretsky (2003-08-05 10:22:00) [3]

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

Dred2k (2003-08-05 09:59:00) [4]

> Anatoly Podgoretsky © (04.08.03 13:41)

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

Anatoly Podgoretsky (2003-08-04 13:41:00) [5]

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 Currencyvalue, этим как бы сразу накладывается ограничение 20.4
Но мы рассматривали не реализацию в Дельфи, а поля в базе, вот Парадокс за исключением Currency/BCD ни чего другого не имеет, что очень огорчительно. dBase же наряду с остальными типами Парадокса изначально поддерживает и true BCD, например можно указать тип поля N10.7, а не N10 в Парадоксе и оно будет храниться в таблице именно как 10.7.
Вообще с true BCD полный бардак, реально они были полностью реализованы только в dBase IV, а после передода его на BDE это было потеряно, их стали просто эмулировать на основе других типов, тоже касается и FoxPro в них никогда не было полной поддержки.

Dred2k (2003-08-04 10:06:00) [6]

> sniknik © (04.08.03 01:16)

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

sniknik (2003-08-04 01:16:00) [7]

> Снова вынужден сказать "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-03 22:01:00) [8]

> 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 (...) этого нет?

Anatoly Podgoretsky (2003-08-03 21:51:00) [9]

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

Dred2k (2003-08-03 21:16:00) [10]

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

Anatoly Podgoretsky (2003-08-03 20:47:00) [11]

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

Dred2k (2003-08-03 19:57:00) [12]

> Anatoly Podgoretsky © (03.08.03 19:26)

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

Dred2k (2003-08-03 19:55:00) [13]

> Anatoly Podgoretsky © (03.08.03 19:26)

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

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

Anatoly Podgoretsky (2003-08-03 19:26:00) [14]

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

Dred2k (2003-08-03 18:34:00) [15]

> Anatoly Podgoretsky © (02.08.03 12:24)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sniknik (2003-08-02 15:35:00) [17]

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

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

SCORPION ZP (2003-08-02 15:10:00) [18]

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

Anatoly Podgoretsky (2003-08-02 12:24:00) [19]

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

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

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

Dred2k (2003-08-01 17:13:00) [20]

> Anatoly Podgoretsky © (01.08.03 17:05)

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

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

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

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

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »