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.