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

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.