Article:        FoxPro 2.0 Change Log Database
Submitted To:   FoxTalk - Glenn A. Hart, Editor
Author:         Maurice Frank
Compuserve:     072167,736
Phone:          (404) 843-5240 (days); (404) 977-7130 (eves)
Date:           November 11, 1991

================================================================

Shortly after FoxPro 2.0 was released on July 12, 1991 Fox
Software began placing updates on Compuserve's FoxForum. By
early November, eight separate updates were released. Although
FoxPro 2.0 can be considered stable, occasional bug fixes are
likely to be released from time to time.

Each set of update files has been accompanied by a text file
describing the changes. Keeping track of these changes is
important, but wading through eight or more change log files
becomes unwieldy. Since all change log files have so far
conformed to a consistent layout, loading them into a database
file makes tracking changes much easier.

Querying the database yields some interesting results. The first
eight change logs document 273 changes to the original product.
246 are bug fixes (nobody is perfect!), 19 are enhancements, and
8 affected compatibility with earlier Fox products. The biggest
trouble spot so far is clearly the BROWSE command which has been
affected by no less than 25 separate changes. Since many FoxPro
developers rely heavily on this command, the unified change log
database provides a complete history of what has been done to it
since FoxPro 2.0 shipped.


Change Log Files

The change log files are named CHNG#.LOG where # is 1 to 8. All
share the same layout. Each entry has a header with three key
pieces of information: the command affected, the category, and
the date fixed. They are all on the same line and are sandwiched
between two double bar lines (ascii character 205). A paragraph
describing the change appears below this header section. Along
with the filename, these four items are stored in fields in the
change log database.

Each record in the change log database also stores the change
log filename and an item number of the change within the file. 
The file name and item number comprise the primary key for the
change log database file. Note that the item number is generated
by the import program. It does not appear in the change log
file. I also decided not to store the path name of the change
log file. The Splitpth udf turned out to be as useful to me as
the overall change log programs.


Change Log Database


The commfunc field records the name of the command, function, or
general aspect of FoxPro 2.0 that was changed. Scanning this
field for patterns can be insightful. For example, at least ten
separate commands have been patched five or more times. Some
commands are listed more than once within the same change log
file.

Category refers to bug, enhancement, or compatibility.
Interestingly, Fox Software has misspelled "compatibility" two
different ways. If these text files were generated out of a
database in the first place, I would not expect to see that
because this field lends itself to a popup. 

The date fixed varies within each change log file. The only
piece of information found in the change log files which is not
stored in the database is the file date. That is usually the
latest date fixed within the file name. The following SQL
command provides a close approximation of the time period
covered by each change log file. (The read.me file also reveals
this information.)

     select filename, min(dt_fixed), max(dt_fixed) ;
     from fp2cl ;
     group by filename

      
Programs


All Change Log programs begin with "CL". One exception is the
generic UDF named Splitpth. This is discussed in more detail
below.

The main program is CLLOAD. It performs some parameter
processing and setup. Then it begins calling other programs
(CLMAKDBF) to create the change log database and index if
necessary. It expects a name for the change log database. If
none is received the name defaults to FP2CL. It calls a udf
named CLCHKLOG to see if a change log file name is already in
the database. If so, the user can choose to skip the file, or
re-import it replacing the existing records.

CLIMPORT is the heart of the system. It uses low level file
functions to process an individual change log file. The FGETS 
function reads in each line of text. If the line contains the
command, category, and date fixed, then they are parsed out into
separate memory variables. So far these have all been located at
the same position in the line so I am hard coding these
positions. They could be calculated, but I decided not to do so
until Fox distributes an inconsistent format.

The lines containing the variable length description of the
change are concatenated and stored in the memvar named details.
This memvar is later gathered into a memo field also named
details. Concatenating this text proved to be quite tricky. A
few adjustments appear in the code.

The CLBROWSE program is a simple way to look at the records. It
displays each records DETAILS memo in a separate window below
the main browse window. I have not included any reports or
queries because the source files can easily be printed. However,
reports filtered on commands of interest might be useful.


The SPLITPTH Udf

The programs to build the change log database make use of a UDF
named SPLITPTH.PRG. This utility splits apart fully qualified
file names and returns one or more pieces needed by the calling
program. The four possible return values are the drive letter,
path name, root file name (the eight character part), and the
extension.

FoxPro 2.0's FoxApp program has a set of udfs that return parts
of a fully qualified file name, but FoxApp uses separate
programs to obtain each part. I would rather use one program,
but I respect FoxApp's more granular approach too.

One interesting aspect of SPLITPTH is its ability to return
values in two ways. The second parameter can contain one to four
characters requesting the drive (D), extension (E), and so
forth. All parts requested are returned in one string. They are
always returned in drive, path, fiel, and extension order.
Alternatively, SPLITPTH can receive separate parameters for each
part and return them individually. This requires the parameters
to be passed by reference. That can be done two ways: prefacing
the parameter with an @ (at sign), or by setting udfparms to
reference.

SPLITPTH does not use any 2.0 specific features, so it can be
used in 1.02 programs.


Conclusion

The change log database enables developers to consolidate
information about bug fixes and to retrieve it using database
commands such as browse or select. Even though future change
logs are likely to be fewer and less frequent (chng7.log had
only three bug fixes), this mini-application may be used for
future versions if Fox Software adheres to the same format. Even
if they do not, the concept can easily be adapted, even to other
software products.

