home *** CD-ROM | disk | FTP | other *** search
/ Programmer 7500 / MAX_PROGRAMMERS.iso / PASCAL / BTP20.ZIP / HISTORY.TXT < prev    next >
Encoding:
Text File  |  1993-06-10  |  9.4 KB  |  166 lines
  1. {HISTORY of BTP - the Btrieve Unit for Turbo Pascal 7.0       V2.0   6/10/93 }
  2. (* ------------------------------------------------------------------------ *)
  3.  
  4. Version 1.0   4/9/91: Initial functioning unit, released 9/5/91.
  5. --------------------
  6.  
  7. Version 1.1   9/8/91: Corrected a problem occuring in Btrieve files that had
  8. --------------------  segmented keys with more than one segment.  The stats
  9.    stored by the BFile.Init constructor were not calculating the number of
  10.    segments properly.  The CreateFile function was also modified to deal with
  11.    the same key problem.  This change forces one more statement to be placed
  12.    in any 'create file' routine.  Any of the 24 key arrays not used in a file
  13.    must have their key flags set to zero.  See Create.PAS for an example.
  14.  
  15. Version 1.2  9/16/91: NOT RELEASED PUBLICLY.
  16. --------------------  Derived a new base object, BRecMgr, from what HAD been
  17.    my base object, BFile.  It made sense to me to provide access directly
  18.    thru an object to the basic, non-file, non-record oriented Btrieve
  19.    operations: Begin/End/Abort Transaction, Version, Stop and Reset.  This
  20.    BLOWS compatibility with any code you wrote under prior versions of this
  21.    unit as the BT function is now virtual.  You should NOT call the ancestor
  22.    BT function in your override...replace it completely as shown in the
  23.    example programs and in BTP.DOC.
  24.  
  25.    BRecMgr has a variant record field to hold info on the version of Btrieve
  26.    the user is running.  That data is set by BRecMgr.Init.
  27.  
  28. Version 1.3 10/11/91: Unit name changed to BTP.  Bug fixed that would give
  29. --------------------  incorrect result in BFile.NumRecs if number of records
  30.    exceeded 32,767.  Made a number of "touch-up" changes to make it easier to
  31.    use dynamic variables of the various data types in BTP.  Note particularly
  32.    that the CreateFile function now requires a second parameter, a pointer to
  33.    a Btrieve file spec as defined in BTP.
  34.  
  35.    The constructors for BRecMgr and BFile now set up a string data field,
  36.    VersionString, equal to the version number of Btrieve running in the user's
  37.    computer.  This is in addition to establishing the record field Version,
  38.    which contains the exact bytes returned by the Btrieve version call.
  39.  
  40.    All example programs were modified to reflect the changes in 1.2 and 1.3.
  41.  
  42. Version 1.4 10/27/91: Nomenclature of data types improved and made more
  43. --------------------  consistent, both within BTP and with TP6's own internal
  44.    Turbo Vision style.  TRecMgr and BFile are now separate "base" objects.
  45.    Added BFixed and BFileExt objects, both descendants of BFile.  Together
  46.    these permit handling any standard fixed-length file, and provide complete
  47.    support for the get/step extended calls, including handling of all the
  48.    drudgery of constructing data buffers.  This was no small task!  For
  49.    extended calls, you need simply insert your filter and extractor specs into
  50.    the provided collections in BFileExt.  The rest of the setup is transparent
  51.    to you, being handled by the object's internal methods and your standard
  52.    override of the BTExt function.
  53.  
  54.    An object of type BFileExt can freely entertain both standard BT and
  55.    extended BTExt calls thanks to encapsulation of the position block in the
  56.    object (see EXAMPLE2.PAS).  However, I recommend use of BFileExt only if
  57.    you are truly going to use extended calls for a particular file.  This is
  58.    because there is about 32K more overhead per BFileExt object than BFile.
  59.    The size of a BFile object is 698 bytes.  The size of a BFileExt object is
  60.    722 bytes, plus the size of the extended data buffer, which I default to
  61.    32767 bytes, plus the size of any items inserted into the two collections.
  62.    Note that the size of a BFixed object is 5043 bytes, to hold room for a
  63.    buffer equal to the maximum size of a fixed length record, and the maximum
  64.    length of a key.
  65.  
  66.    BFile and its descendants now take an Open mode parameter.
  67.  
  68.    The BFile.BT virtual function is now Abstract, to assure you don't call
  69.    it without overriding it.
  70.  
  71.    The BFileExt.BTExt method must be overridden, with the override calling
  72.    the ancestor; i.e. your override must be of a standard form, and must call
  73.    BFileExt.BTExt.  This is because BFileExt.BTExt is what sets the buffer
  74.    length and constructs the buffer for extended read calls.  This is in
  75.    contrast to BFile.BT or BFileExt.BT, which must be overridden by REPLACING
  76.    them, as shown in the example programs and in BTP.DOC.
  77.  
  78.    BFileExt's data fields include two collections.  The FilterSpec collection
  79.    need not hold any objects, but the ExtractorSpec must always hold at least
  80.    one.  Now, for extended calls, you handle these data fields as follows
  81.    (see EXAMPLE2.PAS):
  82.    1:  HEADER is handled internally.  Don't mess with it.
  83.    2:  FILTER's fields are assigned by your program.
  84.    3:  FILTERSPEC collection may or may not hold any objects, depending on
  85.        your program's needs.
  86.    4:  EXTRACTOR must be initialized.
  87.    5:  EXTRACTORSPEC collection must hold at least one object.
  88.    6:  EXTDBUFFER is handled internally.  Don't mess with it, except to
  89.        use it as shown in EXAMPLE2.PAS when you override BFileExt.BTExt.
  90.  
  91.  
  92.    BTP 1.4 IS THE FIRST *SHAREWARE* RELEASE.  The BTP product is no longer
  93.    FreeWare.
  94.  
  95. Version 1.5 11/9/91: New in this release...complete support for alternate
  96. -------------------  collating sequences.  This required modifying the BFile
  97. object and its constructor, and the CreateFile function, and the addition of
  98. data structures for an alternate collating sequence file.  A boolean field in
  99. BFile, HasAltCol, has been established.  The CreateFile function now takes a
  100. third parameter, being the name of an alternate collating sequence file, if
  101. any.
  102.    Also changed in this version:
  103.    BFile has an additional field for a file's actual filespec length.  This
  104. can be useful when cloning a file.  A new function, CloneFile, has been
  105. added, which reduces the cloning process to a single function call, with only
  106. the names of the existing and new files passed as parameters.  Miscellaneous
  107. changes in V1.5 include elimination of a redundant parameter previously
  108. required by the FilterSpec object's constructors.  Added a variant to both
  109. the FileSpec and KeySpec objects to allow easier reporting of certain stats
  110. after a stat call.
  111.    Some minor optimizations done here and there thruout the unit and example
  112. programs.
  113.    BEST NEWS!  The STATS program has been greatly enhanced.  It now produces
  114. substantially the same output as 'BUTIL -STAT', but is a standalone program
  115. and can be freely distributed with your applications (unlike BUTIL) IF YOU ARE
  116. A REGISTERED USER of BTP.
  117.  
  118. Version 1.6 11/25/91: Corrected a typo in example CREATE1.PAS.  Changed the
  119. --------------------  CloneFile function significantly.  It can now clone a
  120. file with supplemental indexes...and do one of the following with such
  121. indexes: drop them (keeping only the permanent indexes), retain them as
  122. supplemental indexes, or make all supplemental indexes permanent.  The
  123. STATS program was updated only to add the ability to report on/identify
  124. supplemental indexes.  To the best of my knowledge, the STATS program can
  125. now truly be said to be a COMPLETE replacement for any information reported
  126. by BUTIL -STAT.
  127.  
  128. Version 1.7 1/11/92: RELEASED ONLY TO REGISTERED USERS.  Corrected a potential
  129. -------------------  problem in the BFile.Init method and CloneFile functions.
  130. Use of typed constants versus variables would create problems due to those
  131. data items retaining values between calls.  Replaced them w/variables.  Bug
  132. only seemed to appear if a TP6 unit was created using BTP.TPU, and that unit
  133. was then used in a separate source program.
  134.  
  135. Version 1.7A 2/28/92: Corrected a minor bug that could appear with Btrieve
  136. --------------------  files of a full 24 key segments.  The CountSegments
  137. procedure in both BFILE.INIT and CREATEFILE() had an incorrect expression
  138. as a termination test in a REPEAT..UNTIL loop.
  139.  
  140. Version 2.0  6/10/93:  Numerous changes throughout the product.
  141. --------------------
  142. NOTE: This version breaks compatibility with prior releases in a number of
  143.       places.  Most constructors take additional parameters (owner name the
  144.       most significant).
  145. 1.  Rewritten to make use of several features of TP/BP 7.0, such as the
  146.     "inherited" and "const" keywords, and the use of open arrays in at least
  147.     one place.
  148. 2.  Enhancements throughout the product to handle owner names.  The base
  149.     object BFile, and the CreateFile and CloneFile functions were enhanced
  150.     to readily deal with owner names.
  151. 3.  Added a descendant of BFile, BSized.
  152. 4.  Added the AddSuppIdx function to the base object, BFile.  This makes it
  153.     trivial to add a supplemental index to a file.  Uses its own internal
  154.     buffers, not disturbing your "working" buffers.
  155. 5.  Major improvements to the CreateFile function (see CREATE1.PAS and
  156.     CREATE2.PAS) that permit Btrieve file creation with two program
  157.     statements.  This was made possible in part by the new function
  158.     NewKeySpec.
  159. 6.  Some nomenclature changes made for consistency.
  160. 7.  Minor other cosmetic changes to code in the BTP unit.  No known bugs, per
  161.     se, were found or corrected.
  162. 8.  The example and utility programs were rewritten, and in some cases over-
  163.     hauled.  The STATS, CLONE and CRUNCHx programs now deal with owner names.
  164.     The EXAMPLEx programs are hopefully more meaningful and helpful.
  165.  
  166.