
                             DBF.BIN:



           An External Module to Import .DBF Files into Emerald Bay
             and to Edit the .DBF File from Vulcan Applications.


Written by: Robin M. Day using libraries published by Ratliffe Software
Productions Inc. (RSPI) and compiled with the Borland C++ compiler, ver 3.01.
IMP_DBF.VO was written in Vulcan, an XBASE programming language
published by RSPI and compiled using the Vulcan compiler (vc.exe).
The system was tested using Vulcan ver 3-1363 of 02/10/'92, and Emerald
Bay engine ver. 3.03.



Contact the author at Compuserve 71042,2647 or USENET/INTERNET
Robin.Day@canrem.com



CONTENTS:     Introduction ...............  Line 36.
              Capabilities ...............       55.
              Modules (~described) .......       74.
              Limitations ................       96.
              Comments ...................      121.
              Price ......................      127.
              Liability ..................      148.
              Copyright ..................      165.




Introduction:

(I have assumed that the reader is familiar with the Emerald Bay and
Vulcan system.)

The current version of my module imports a .DBF file about 2.5 to 4 times
as fast as the quickest arrangement that I can now imagine using
FILEIO.BIN (according to summary test results - feel free to dispute the
exact ratio) . It is quick enough to use for importing .DBF files into
the EB system and for editing the original .DBF and it's imported image
in EB/Vulcan concurrently without the benefit of Stone.exe. I have
tested my routines on a 386-33 Mhz. intel based system with a 387
coprocessor. I could guarantee that it would usually perform 4 times as
fast if I deleted the string formatting features which eliminate
'deadspace' at the end of imported strings and so forth, but most people
would rather wait an extra second or two for properly compressed field
strings. It is closely comparable in performance to '.exe' files which
do the same thing (-~15%). It works for me - see if it works for you !

Capabilities Which DBF.BIN Provides:

            1) Imports (any ?) .DBF file.  Memo and character fields are
            limited to 512 bytes. The current version maps all fields to
            character fields in EB. It requires no input after calling
            imp_dbf('.DBF_nam','EB_nam','tbl_nam','memo_flg') Use
            Stone.exe if you don't need to edit the source file and
            don't need access from within the application.

            2) Edits the source .DBF file and it's EB image
            concurrently. Please understand that the .DBF file probably
            should not be actively 'shared' at the time of importing to
            EB and editing.

            Comments:  Editing is performed using an external FUNCTION.
            Write your own routines.The user should provide a validation
            routine so that EB changes are compatible with the original
            .DBF file field formats.

Modules: (~described)
            1) imp_dbf.vo : contains two functions

            a) imp_dbf('.DBF_nam','.EBD_nam','EB_tbl','memo_flg');
            -> .EBD_nam is the name of the NEW recipient EB database.
            -> EB_tbl is any name you wish for the EB table mapping of
            the .DBF file.
            -> .DBF_nam is the name of the source .DBF file including
            .DBF extension.
            -> memo_flg :'tT' to import values in .DBF memo fields,
            'fF' to ignore .DBF memo fields.
            Returns (-99) on error, else +'ve number.)
            b) edit_dbf(rec_no,field_number,'file_name') -rec_no is the
            record number of the current EB edit object. Field_number is
            the field NUMBER of the changed field, and 'file_name' is
            the name of the target .DBF file including the .DBF
            extension. I suggest use with 'updated()' in an edit
            routine. Returns (-99) on error, or +'ve number on success.

            2) DBF.BIN contains the performance enhancing features of
            this system.  Just load it, and let imp_dbf.vo do the rest.

Limitations:This system cannot handle .DBF record sizes larger than 5 k.
            I can probably increase this limit. Memo/character fields should
            not be larger than 512 bytes (the EB limit for character
            fields ?). Only character type memo fields positioned as
            such in the .DBF file will be handled normally. This system
            is not designed to import binary files which are part of a
            memo field system. Imp_dbf.bin moves the the core data of
            the .DBF file for people in a hurry. I see no great
            technical obstacle to importing .FPT or other memo field
            systems but it may as well be done using FILEIO.BIN; I'll
            add a function later if there's demand. I don't know if
            there are any meaningful limits to the size of .DBF files
            that it can import. The demonstration version will handle
            only one .DBF file per application session, but the full
            version will import as many files as you wish per session.
            Using the demo version, you will not be able to edit the
            .DBF file from vulcan once the session during which the
            file is imported has ended. It would not be wise to assume
            that your EB copy accurately reflects the current contents
            of the .DBF file if the .DBF file is currently being used in
            another system, so in many circumstances the user shall
            import the .DBF file afresh more or less every time he
            wishes to view or edit it.


Comments:   edit_dbf() requires a field NUMBER as one parameter. I have
            thoughtfully provided a function called FLD_ID() which
            returns 'field number' given 'field name'. Use edit_dbf()
            with 'updated()'.  It should be fairly simple to splice
            these functions into your standard editing routines.

     Price: The current market size  for this system is small, and it
            took me a while to develop and test a system that could take
            advantage of Vulcan's .BIN file capability. Such
            philanthropy should be rewarded. If sales justify any
            further effort, I will write more .BIN,.EXE and .vo routines
            for EB/Vulcan. The performance of my system seems to be
            comparable (15% slower ?) to that of stand-alone .exe files
            which do the import phase of the operation AND it uses
            Vulcan-Space! The .BIN file size is about 8 k.; the .vo file
            size is about 2 k.. The equivalent .exe file is 45 k. in
            size. My methods are slightly unusual, but seem to be
            effective. What do you think that IMP_DBF is worth ?  I have
            to base the price on the number of stations at the site.Site
            licenses may be negotiable, but what would you think about
            $15.00 for a single station package which includes the
            FLD_ID.BIN function ? I'd have to sell a large number of.BIN
            files at that price to make a fair wage for all of my own
            skilled time that I have invested in learning the system and
            developing and testing something that is truly effective and
            in my judgement, better.

Liability:  If my .BIN file 'crashes', chances are that your compiled
            executable can continue on it's merry way and I have tested
            it in Vulcan with every .DBF file available to me. It seems
            well behaved. If you buy it, and it scrambles your system
            files, I'll probably give you your money back,but you should
            try before you buy, to show that it will work for your
            system. If the instigating file or files are highly abnormal
            in some dimension, then I probably wouldn't want to give you
            your money back, especially if you've already tested my .BIN
            file and accepted it for use which you define to be
            'normal'. I wouldn't put my name to it if I didn't think it
            was O.K., and hadn't tested it.
            Please send your detailed description of any faults, bugs or
            problems which you find with the imp_dbf.bin system to the
            author at compuserve 71042,2647 or to: Robin.Day@canrem.com
            via USENET/INTERNET.

Copyright/ 'fld_id.bin' 'imp_dbf.vo' and 'dbf.bin' are mine. You may
 Licenses:  test these functions in your applications for 30 days from
            the date of acquisition. If you wish to continue using them
            after that time, you must contact the author to arrange use
            and distribution licenses.


EB stands for "Emerald Bay", which is a trademark of Ratliff Software
Production, Inc., as are 'Stone' and 'Vulcan'.

I may be able to write a customized external module to your
requirements.  Feel free to contact me with your request for a quote.
