

          DATAdesign conversion programme

Use as follows:

1) Exec programme - the program needs
                                      the QLIBERATOR runtimes,
                                      the Menu extensions, and of course
                                      the DATAdesign engine v.3.xx
   to be installed first

2) Give the name of the file to be converted: this must be a valid, old DATA-
   design file. The program will keep prompting until this is so.
   When thus given a file name, Convert reads part of that file (to make sure
   that it is indeed a DATAdesign 1.xx or 2.xx file) and then displays all the
   fieldnames of that file, and the type (the type is char at the beginning).

   You can now determine what the type of the fields is going to be in the
   new database: Clic on all fields you wish to be of a certain (same) type. The
   fields will be selected. Now clic on one of the types (i.e. Char, short,
   double, IEEE or date): the fields which were selected will become of this
   type.

   The DATE item needs some further explanations: Most users will stock dates
   as a 10 character string eg. 31.01.1993, or, more analytically, in the
   format Day Month Year DD.MM.YYYY; or actually - DD <sep> MM <sep> YYYY <sep>
   where <sep> is any separator such as '.' or '/' or '\' etc...   Variations
   on this theme exist of course, some use the YYYY.MM.DD format, whereas
   many americans will use the dreaded MM.DD.YYYY format.
   Whatever the format used by you, it will be more efficient and probably
   faster if you stock your date information in DATAdesign in (yet)
   another form: a long word. This only takes 4 bytes, instead of the ten used
   by the other forms. The long word corresponds to the way the QL internally
   handles dates. A date corresponding to a long word can be converted into
   a string by the Basic DATE$ (number) function: print DATA$(0) will print
   1961 Jan 01 00:00:00. So, if you convert a date into a long word, there is
   an easy way to re-convert it back into a date
   (eg :            dd_err=0               : rem set error flag
                    a=getlong(x,y)         : rem get long
                    if not dd_err
                       a$=date$(a)         : rem if no error, get date string
                       a$=a$(1 to 11)      : rem and extract the date
                    endif


   The other conversion, from a typical date string in the DD.MM.YYYY format (or
   any of its other variations) is not so easy and is accomplished here by the
   new MKDATE keyword (see separate info file on this keyword). When clicking
   on the DATE item, the conversion program asks what type of date format is
   used in the file to convert: this MUST be one of the three formats shown
   above - but the separator used does not matter at all. If the date is not
   in this format, you should store it as a string. If you do not have a date
   string in this format, but still try to use the date option, the conversion
   program will certainly not function correctly...


   ATTENTION: IT IS YOUR RESPONSIBILITY TO MAKE SURE THAT THE TYPES ARE POSSIBLE
   FOR THE FIELD IN QUESTION: IF YOU DETERMINE A FIELD TO BE OF A NUMERIC TYPE,
   BUT THE DATA IN THE OLD DATABASE IS STRING (I.E. CONTAINS NON-NUMERIC CHARAC-
   TERS) THEN THE PROGRAM WILL JUST STOP WITH AN ERROR...! LIKEWISE, THE DATE
   OPTION SHOULD ONLY BE USED FOR DATES STORED IN THE FORMAT DESCRIBED ABOVE.

3) Now give the name of the new file - this must include the device, but must
   not contain the _ddf extension, which will be added automatically.

4) Determine whether the new file is to be disk or memory based.

5) Hit the "DO" item - the (slowish!) conversion process will begin
   When the conversion is finished, you will be informed...


--------------------------------------------------------------------------

Configuration:  It is possible to configure the Converter, using the standard
public domain Config programme for the Pointer Environment

Programmable items are:

          - colourways for the main window, for the window listing the
                       fieldnames and for the button
          - whether, by default, files are to be mamory based or not (if not,
            they are, of course, disk based).




                    Paris, 1993 Mar 11 17:44:21
                    W. Lenerz
