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

5.7.00.01 Release Notes

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

(*nix) #1001

    filePro didn't properly read free space on some systems with more

    than 4GB of free space.

(*nix) #1127

    When executing SYSTEM() commands in processing, filePro now

    restores the original umask value.

(All) #1130

    If you have a protected lookup to the main file, and end up on

    the same record you are updating (such as via a GETNEXT loop),

    and modify that record, and then move off the current record, the

    lookup (ie: the record you are sitting on) will be written and

    unlocked.  This leaves you in update on an unlocked record, with

    the old data.

    filePro will now prevent you from modifying the current record

    via a lookup while in update mode.  (Just as it prevents you from

    deleting it.)

(All) #1169

    Some edits punctuation that occurred within a literal when that

    literal was within the same punctuation, could cause filePro to

    crash.  For example:

        < "<" >

        ( "hello(there" )

(All) #1170

    When restructuring files larger than 4GB, ddefine could hang.

(All) #1171

    If you run a report with sort/select processing, but no automatic

    or output processing, it is possible for *report to crash when it

    gets to the grand totals.

(All) #1173

    When using fuzzy browse mode, if you search on an associated

    field, it is posible that the field name will be rejected upon

    returning to the "enter field" screen.

(All) #1179

    If you have a protected lookup using an alias, and modify the

    lookup, and then execute another lookup using the same alias

    without issuing a WRITE, the previous lookup record will be

    unlocked before being written.  This leaves a small windows of

    opportunity to have another process read and lock the record

    before the first process writes the new data.

(All) #1180

    A browse lookup-dash did not properly handle record locking,

    either leaving the previous record locked, nor not locking the new

    record.

(All) #1181

    On files with more than 99,999,999 records, @RN was not properly

    set to 10 characters, causing erroneous record numbers to be

    reported for record 100,000,000 onwards.

    Note the following issue still remains for now;  If you enter    

    *clerk on a file with less than 100 million records, and have @RN

    on the screen, and then start adding records so that the file   

    then contains more than 100 million records, the value of @RN as

    displayed on the screen will remain at 8 characters until you  

    switch screens.  Other references to @RN will properly adjust to

    10 characters.

(All) #1182

    If you have a file with no automatic or input processing, and use

    "F-Form" to print a form that has output processing, then use "7-

    Change File" to another file with no automatic or input

    processing, attempting to then update/add a record can crash

    *clerk.

(All) #1184

    A selection set which includes 12 AND/OR items in the sentence

    can crash filePro.