=====================================
5.7.(00,01,02,03,04).07 Release Notes
=====================================
(Windows) #1226
The Windows version of filepro didn't show the user limit on the Alt-F10 screen.
(Windows) #1271
If you have a large number of large arrays (ie: 96 arrays of 1000 elements each) in processing, filePro may be slow to exit.
(Windows) #1277
Setting PFEOF changes the "Press <--+ to continue" prompt. (All) #1278 LOCKED(-) would always test "false".
(SCO OSR5 only) #1279
Running an FPSQL query with a WHERE clause containing a date literal could crash.
(All) #1280
Using the processing debugger, if you use "E" to enter an expression ising an invalid field (such as "imp(10") on a 9-field import), filePro can crash after giving the error message.
(All) #1288
If you have a lookup to the current record in the main file, and MEMO EXPORT a field via the lookup, filePro will complain that you are trying to modify the current record via a lookup.
(All) #1289
When hardcopying a file in ddefine, if the output was not to "PDF:", the heading wasn't printed on the first page.
(*nix) #1290
On some *nix systems, an idle runmenu can wake up every 3 minutes and cause a spike in CPU usage for 1 second. While not usually noticable, this can be a problem on a system with many users.
(All) #1291
If you execute a DELETE (no lookup name), and then a CALL, the record was not deleted.
(Linux only) #1292
On some Linux systems, filePro would see a different MAC address than reported by "ifconfig" or "ip addr".
=====================================
5.7.(00,01,02,03,04).06 Release Notes
=====================================
(All) #1272
When printing to a PDF document, if you have an FPML tag with
attribute="value" (using quotes around "value") and "value" is
longer than 1024 characters, filePro could crash.
Note that this could also happen if you tried to embed a PCL
file which happened to include "just the right sequence" of
characters.
(All) #1273
fPSQL would crash on files with MEMO/BLOB fields. Note that
such fields are still not yet supported, but fPSQL will no
longer crash on such files.
(SCO only) #1274
The HASH() and HMAC_HASH() functions would crash on SCO if
passed an invalid hash name.
(SCO only) #1275
There appears to be a bug in the SCO C runtimes library, where
the text-to-binary (strtod) function would return "not a number"
for valid numbers, in some not-yet-determined scenario. This
version of filePro works aorund it.
This would manifest itself within filePro in the power (^)
operator sometimes returning "-NaN".
(*nix only) #1276
License check in 5.7.xx.05 versions of *nix filePro wouldn't
work correctly for MAC-based licenses.
==================================
5.7.(00,01,02,03,04).05 Release Notes
==================================
(All) #1272
When printing to a PDF document, if you have an FPML tag with
attribute="value" (using quotes around "value") and "value" is
longer than 1042 characters, filePro could crash.
(Windows) #1250
If PFDSK wasn't set, dexpand could fail to check disk space.
(All) #1251
The "grace period" warning wasn't always shown properly when
running in the grace period.
(Linux) #1254
Attempting to resolve fields in dscreen on a screen with @UB
and/or @CB could crash on Linux.
(Linux) #1264
PFMONO=ON wasn't respected on Linux.
(*nix) #1265
Two new termcap entries -- PL and PM -- represent a second set
of keys which can be used to DELC and INSC, respectively.
(Windows) #1267
When sending output to a PDF file, "H"ardcopy in *clerk might
not open/print the PDF until you exited.
(All) #1268
If you execute PRINT @SBRK on the very first record of output,
*report might crash.
===============================
5.7.(00,01,02,03).04 Release Notes
===============================
(All) #1230
Removed starting splash screen and added customer and version to
the clerk Index Selection screen.
(All) #1223
DOKEY did not switch screens if passed a digit.
(Windows) #1228
The default location for the PFCHECKLOCK=ON log file is moved
from the root directory (which is not writable on current versions
of Windows) to the user's HOME directory.
If %HOME% isn't set, filePro uses %HOMEPATH%. If that is not
set either, then filePro will use the user's "my documents"
directory.
(GI) #1229
When using @GUI.RECVFILE(), if the client gets an error (file not
found, permission denied, etc.) or if the file is zero length,
filePro would write garbage to the destination file.
(All) #1233
On filePro-MySQL, it was possible to crash filePro with certain
combinations of lookup-dash followed by "if: not -" and "if: -".
(All) #1234
Using "if: locked(-)" could crash filePro.
(All) #1235
If you are sitting in an ODBC file, and have a lookup (not lookup
dash) to the same file, filePro can crash when the file is closed.
(Syntax check in *cabe on such processing could crash as well.)
(All) #1236
If you use one of the PRINTER commands to send the output to a PDF
destination, followed by PRINTER RESET, and then come other PRINTER
command to set the destination to a non-PDF destination, that output
will be "lost", and no output generated.
(All) #1237
If you have a menu command with "@" for wait-on-return, and press
Ctrl-C/Del/Break at the "Press enter to continue" prompt, runmenu
would exit completely, even if this was a nested menu.
(All) #1241
If you have a memo field which you grow over time, such that the
memo becomes fragmented, and then shrink the memo such that the
last fragment is no longer needed, the blob file will be in an
inconsistent state. If you then grow the memo again, the file
will be corrupted such that either (1) filePro will crash when
upating that memo, or (2) two memos will be "cross-linked"
together.
(ODBC/MySQL) #1242
If you are sitting in an ODBC/MySQL file, and have a (non-dash)
indexed lookup into the same file, GETNEXT will always find the
record after the one you're sitting on, and not the lookup record.
(ODBC/MySQL) #1243
A browse lookup on an ODBC/MySQL file to itself would not respect
the "must match" flag.
===============================
5.7.(00,01,02).03 Release Notes
===============================
(Quikstart) #1188
If you have a DECLARE GLOBAL variable in input processing, and CHAIN
to another prc file, and then CHAIN back to the original input
processing, the DECLARE GLOBAL variables would be cleared.
(All) #1204
If you have a processing table created outside of filePro, with a
"then" line longer than *cabe's 127-character limit, *cabe may crash
on Windows 8 systems with a stack corruption error when you try to
save the processing.
(All) #1205
There is now a "-FC" flag to ddir to delete selection sets.
(All) #1206
If you have a CALL from automatic processing, and that called table
closes a lookup which is already open in input (or output) processing,
then filePro may crash when that lookup is accessed in input (or
output) processing.
(All) #1207
If you have a protected lookup-dash, followed by an unadorned "WRITE",
the current record would be unlocked.
(All) #1208
If, in add records mode, you have a lookup to the current file, a
DELETE, and a lookup-dash, you can get a "deleted key not found" error
on the lookup-dash.
(All) #1209
If you executed an unprotected lookup-dash while in update mode, the
resulting record was left unlocked, despite being treated as being in
update mode. Such a lookup will now be implicitly locked.
(All) #1211
filePro didn't properly handle deleting an ODBC connection:
ODBC_CONNECTION handle DELETE
if there were open recordsets on that connection. filePro will now
implicitly close (but not delete) any recordsets on that connection
prior to closing the connection. (The recordset handles will remain
valid, but the only operation permited on such recordsets is to delete
them.)
(Windows) #1213
When comparing a date field to a non-date field, it was possible to
cause a Windows "debug assertion failed" error in "just the right
combination of circumstances".
(All) #1214
If you are adding a new record, and have a lookup-dash to a record
which is locked, and press BREAK/DEL while the "waiting for record
to be unlocked" message is on the screen, filePro would delete the
lookup record, rather than the yet-to-be-created record you were
sitting on.
(All) #1215
Attempting to do date arrithmetic on a date field containing "/OV"
could cause filePro to hang/crash. filePro will now correctly return
"/OV" in those cases.
(fileProGI) #1216
Under GI, ddefine didn't move the cursor into another field if you
clicked the mouse.
(All) #1217
If the main file is encrypted, and you have a lookup to the main
file, and you then close that lookup, further access to the main
file may no longer decrypt/encrypt correctly.
(All) #1218
Task item #1181 caused @SF/@SH on output formats to always be blank.
(Note that they still worked in output processing. It was only on
the output format that failed.)
(*nix) #1220
Fix for #1127 (restore umask for SYSTEM) caused ddefine to not
create new directories with the correct permissions.
(Windows) #1221
5.7.01 (and later) fpcopy didn't properly rename files under Windows.
(All) #1223
DOKEY would not properly handle a number to switch screens.
=========================
5.7.01.01 Release Notes
=========================
(All) #1175
When using dexpand to pre-expand an encrypted file, the new
records could contain garbage.
=========================
5.7.00.02 Release Notes
=========================
(All) #1013
The @WORDWRAP[] data would include the newline at the end of the
last line, even when requesting that newlines be stripped.
(All) #1058
licinfo did not respect PFLICFILE.
(Windows) #1131
Some Windows systems were unable to read the MAC address for
licensing.
(All) #1145
Grace period splash screen time can now be dismissed by pressing
a key.
(All) #1178
A selection set passed with "-s", which had a "-" in the name,
would be truncated at the "-".
(Windows) #1185
Some Windows systems were unable to read the Windows product key
for licensing.
(Quikstart) #1186
Datemath on 2-digit-year fields which overflowed the 2-digit-year
range would result in erroneous values, rather than "/OV". (Quikstart
only.)
(All) #1190
Fixed cosmetic errors when displaying record numbers beyond
99,999,999.
(All) #1191
Selection sets in files larger than 99,999,999 records which
referenced @RN, did not properly select records.
(All) #1193
INPUT POPUP had an undocumented limit of 70 characters for the
input field. If the field was longer than 70, the remaining
characters were filled with spaces. This limit has been removed,
and the field will now scroll if too wide for the screen.
(All) #1194
Fields @PM, @PW, @PX, @PY, and @PZ defaulted to the value " ",
rather than "".
(*nix) #1195
The USER command could leave defunct processes after CLOSE.
(All) #1196
@TS is now (10,.0) on files larger than 99,999,999 records.
(All) #1197
More information will be recorded in the license log file for
license failures.
(All) #1199
If you have an F6-defined browse lookup which requires more than
73 characters to display the data, and then edit the format, the
end of the data of the selected record would "bleed" into the
format.
=========================
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.
=========================
5.7.01.00 Release Notes
=========================
(All)
Encrypted filePro key/data/blob.
(All)
"PFREADONLYWARNING=OFF" turns off all read-only warning messages.
(All) #1169
Some edits punctuation that occurred within a literal, when that
literal was within that 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.
=========================
5.7.00.00 Release Notes
=========================
All platforms
All bug fixes from 5.6.11 and prior revisions are included
in this product. Refer to the readme_5.6.11.txt file.
SCO OSR5
Note that on SCO's OSR5, "AF_INET6" is unknown, as our OSR5
development system does not support IPv6 as far as we can
tell.
All platforms
If you pass an unknown family to SOCKET(), AF_INET
("IPv4") is used.
If you pass an unknown family to BIND2(), AF_UNSPEC
("any") is used.
All platforms
xx = @ODBCEXCEPTION.CLEAR
This will clear any text currently returned
by @ODBCEXCEPTION[]
Windows
Windows GI GIclient -pq local printer support
All platforms
When using ENCRYPT() and not passing a nonce (ie: allow
filePro to generate the nonce), it was possible to generate
the same nonce on two calls in a row.
All platforms
The HMS edit in filePro 5.7 now supports times up to
1999999999:59:59, rather than the previous limit of
596523:14:07.
Windows
Under Windows, if a filePro program was run from the task
scheduler, and an error occurred, filePro would wait forever
for the non-existent user to press Enter to continue.
All platforms
If you have a MEMO EDIT command within @WUK processing, and
have the "-d" flag on the command line, the memo editor prompts
were left on-screen upon saving the memo.
All platforms
In some cases, if you get a syntax error on a "large"
processing table in rcabe, the program will crash upon
pressing Enter at the error message. Note, this is rcabe only.
All platforms
If you have an index built on a field with a user edit (ie:
not a system edit), and you add or delete edits prior to the
edit definition, dclerk might not respect the edit in the
"enter index search data" dialog after the initial scan.
Note that this is typically harmless, but it can interfere
with the behavior of right-justified edits.