> -----Original Message-----
> From: Helen Borrie [mailto:helebor@...]
> Sent: Martes 11 de Julio de 2000 19:36
>
> There is very little documentation around about converting existing ISAM
> dbs to InterBase. This is the main reason we started this list.

That's one of the main problems. We hope that people will start worrying
about keeping the consistency of operations per themselves and instead get
acquaintance with transactions. So, you control the logic and not the
implementation details.

> Those who
> have done conversions can help those who haven't. We keep the postings -
> suggestions, trials, tribulations, etc. and use them to build
> source-database-specific guidelines for those who come after.

That's the idea. We'll try to help but because we don't have anything
structured yet, we need questions... specific questions are better. People
are welcome to share their woes in the conversion process. We all need to
learn.

> To start the ball rolling, the FASTEST way to do a conversion is
> to output
> your tables to fixed-length text files and bring them into interbase as
> EXTERNAL FILES.

Probably. The other alternative is to use IBLoad, available at DSP (Delphi
Super Pages). I have the IBLoad for IB5 that the author sent me, but I need
to see if it can work with IB6.

> But, if you have blob fields in the old database, you can't use
> this method.

That's a problem and we need to find a workaround. If the BDE (ouch, my
fingers are hurt each time I type "BDE") can connect to both source and
target, it's possible to exorcise it to translate the BLOB fields after all
other text-based fields have been introduced. An update by PK would suffice
just to introduce the BLOB field(s) although I don't defend it as the most
brilliant suggestion.
If the BLOB fields were used only to keep text and they are not very large,
it should be possible to use the f_StrBlob() function in Greg's freeUDFLib,
but this will require to insert this call in the input script file and also
to define such function in the target IB database.

> Your next place to go is to a datapump. I think Delphi's datapump will
> have problems if you want your new database to use Dialect 3, because it
> uses the BDE and the BDE's latest Interbase driver doesn't know about the
> Dialect 3 datatypes.

Also, datapump might have problems with COMPUTED fields in target IB
databases. If it's based on BatchMove, probably this problem exists. I found
that the only solution was to insert through a simple view that skips the
COMPUTED BY defined fields in its select statements.

> For datapumping, the best tool to use is
> the datapump
> in Claudio Valderrama's IB_Wisql.exe, which you can download free
> from the
> IB Objects site.

Helen, "minor" correction: IB_WISQL is made by Jason Wharton... I only have
enhanced it a couple of times. There's a problem: usually is the BDE the one
that reads XBase formats. I know Jason introduced some capabilities, but I'm
not sure if he targeted Xbase or Paradox, I need to check.
Speaking from XBase, one advantage of Dbase/Clipper/Fox is they share a
common format, so what's valid for Dbase is generally valid for reading
tables in the other variations.
I found some background information in my lovely IB4.0's User's Guide, I'm
trying to adapt it, listing first Xbase format and then IB format:
+Character(n) => varchar(n).
+Number => smallint, integer or numeric(x,0), depending on your width. If
you need to control the number of decimal places, then use
numeric(fieldwidth,decimal_places)
but please remember that decimal_places are subtracted from fieldwidth, so
the difference is the number of digits available in the integer part.
+Float => float or double precision, depending in your needed accuracy.
+Date => timestamp (also called DATE in dialect 1 only; in dialect 3 you
have DATE-only, TIME-only and TIMESTAMP).
+Lock => character(24)
+Bytes => BLOB (if the bytes are a few, they can be managed with CHAR(n)
CHARACTER SET OCTECTS instead, but I still need to try this option)
+BOOL => create a domain with your favorite type: it can be
CHAR(1) or smallint, for example and later define your fields using this
domain.
+Memo => BLOB SUB_TYPE TEXT

> SCRIPTING vs INTERACTIVE METADATA CREATION
> There are tools around that let you create tables and add metadata
> interactively. Just from my own experience, this is the worst way
> to build
> an SQL database.

Don't know why. I have used CASE tools to create a db's schema, then
instruct them to target IB, but I edit the script first to customize it and
then use it against IB through isql.exe.

> You have no documentation; and there is no way to make
> sure objects get created in the right order.

Maybe you were speaking only about "database editors" or "after CASE" tools,
not CASE products. With ER/Studio, it seems to address the problem of the
order in table declarations.

> When I make a new database, I have four scripts with names that reflect
> their creation sequence.

Not surprised at all. I'm not as ordered as you... I'm XY. :-)

> Let's get this ball rolling...
>
> Helen

That's the only thing we can do until more questions arise.

C.