(ODBC) #726
PFODBCCOMMITTYPE=n
Selects the open-commit-type to use for high-level ODBC data sources,
where:
0 = "SELECT * FROM tablename" (default)
Very slow on some data sources with very large files,
but uses nothing non-standard.
1 = "SELECT * FROM tablename WHERE id_field = nnn"
(Where "id_field" is the name of the ID field, and "nnn"
is a valid ID.)
Usually faster, but may be slower on some systems, as
filePro must first determine a valid ID to use.
2 = "SELECT TOP 1 FROM tablename"
Fastest version, but "TOP 1" is non-standard and not
supported everywhere. Will cause ODBC failure on those
DSNs that don't support it.
(fPSQL) #1
fPSQL now respects PFUMASK for output files it generates.
(All) #237
If BREAK OFF is executed in a CALL/CHAIN process, it now remains off
upon returning. Also, it is restored to ON if you go to a new record.
(*nix) #285
fPCopy didn't copy formats with names longer than 14 characters.
(Network) #409
If PFQUAL is set to a non-existent qualifier, the network version of
filePro gave an incorrect error message.
(All) #550
The page number was not reset before F8/hardcopy in *cabe.
(All) #634
DECLAREd variables over 34 characters caused errors in *report.
(fileProGI) #663
If you define buttons while displaying a record, go into browse, and
come back, the buttons are gone.
(All) #666
WRITE was not blocked in a table CALLed from automatic.
(All) #681
PFCHECKLOCK didn't pick up some unprotected writes in browse lookups.
(All) #684
When defining processing from dmoedef, PFTOKSIZE was not respected if
the file had no automatic processing table.
(fPSQL) #706
A query with a WHERE clause on a field with an automatic index built
on it could fail if the index was built in descending order.
(All) #708
DECLARED variables defined without the ",g" attribute were not cleared
between records.
(Linux) #711
Running "dcabe filename prcname" could crash on some Linux systems.
(All) #712
PFLOGAPPEND was actually LOGAPPEND. Changed to PFLOGAPPEND as per
documentation.
(All) #717
Given the correct sequence of keystrokes, dmoedef could release its
lock on the output format, thereby allowing more than one person to
be updating it.
(All) #714
EXPORT ASCII with both "-a" and "-x" flags didn't work.
(All) #719
If you modify an index using the "save options without rebuild" and
then tried to rebuild a different index, it wouldn't rebuild.
(*nix) #707, #722, #736
Some output formats saved under 4.8 dmoedef would crash 5.0 dmoedef.
(*nix) #724
Only root could delete files in ddir.
(All) #725
EXIT within a CALLed table did not exit, but acted like END.
(All) #727
"CLEAR arrayname" when the array is aliased to real fields did not
cause the record to be written if that were the only modification
made to the record.
(All) #728
ddir's "delete index" showed all index letters/numbers, even if those
indexes did not exist.
(Linux) #729
ddir would crash when deleting indexes.
(All) #733
dxmaint's "save options without rebuild" could corrupt idex.
(All) #734
When using *cabe's lookup wizard, using a non-existent qualifier in
the filename would crash *cabe.
(All) #735
dscreen would resolve @PD to only 20 characters, when it's really 80.
(All) #740
Although @ONCE in *report is documented as being run prior to any
output being done, it was run while sitting on the last record read
during the sort/select process. Some people thought that this meant
that it was sitting on a selected record.
@ONCE has now been fixed to be not sitting on any record. However,
some people depend on their incorrect interpretation of the old
behavior, so setting PFOLDONCE=ON will "revert back" to a modified
version of the old behavior, where it will now be run while sitting
on the last record _selected_ during the sort/select process.
Note that PFOLDONCE=ON may disappear in some future version.
(All) #747
If you were to DECLARE the same variable more than once, and then
press F6/D in *cabe to show dummy fields, *cabe could crash.
(All) #750
When a print code requiring a space is on an output format, and you
use F7 block functions to move it, the '%' marker is left behind.
(All) #752
When using F6 in pmaint's printer definition screen to change to
printer type, if you select a type with a shorter name than the
one currently there, the field was not properly cleared.
(All) #753
filePro used to accept a period in variable names. This is now not
allowed (it never should have been allowed in the first place), in
order to permit enhanced functionalities. To revert to the old
behavior and allow periods in variable names, you can set
PFLONGVARDOT=OLD. Note, however, that this will disable certain
features, such as access to ODBC and biometrics, which require that
periods not be allowed here.
(All) #757
BLOB/MEMO functions did not work within lookup files.
(All) #766
*cabe could crash when accessing a zero-length prc file.
(All) #767
MIN/MAX functions did not properly handle expressions as parameters.
(All) #80
Printing of MEMO fields now available.
(Network) #191
The network version of ddefine did not create qualified indexes on
new files.
(All) #709
EXPORT ASCII/WORD would always export the same number of fields,
regardless of whether the fields were assigned to on each record,
even if they were only referenced in a comment.
Now, filePro will only export the number of fields as the highest-
reference field actually assigned.
For example:
If:
Then: out[1] = 1 ; out[2] = 4
If: xx = "y"
Then: out[3] = 3 ; out[4] = 4
If:
Then: ' out[5] = 5
filePro would previously always exported 5 fields. Now, if x="y"
is true, it will export 4 fields, and if false will export 2 fields.
To revert back to the old behavior, set PFEXPORTALL=ON.
(All) #282
If you do a fuzzy browse lookup on a field that has an index built
on it, the wrong instance will be shown in the browse.
Also, if you were in index mode on the main file, the wrong instance
would be shown, even though @AF was correct.
(All) #770
If you perform a browse lookup with a "-m" (must match) flag on an
index built across multiple fields, and the major sort key is a date
or time field, the "must match" portion was limited to the major sort
key only, regardless of the mlen parameter.
(All) #758
When using a browse lookup on a multi-field index, with "-m" (must
match) across multiple fields, it was possible to get an erroneous
"top of file" after scrolling down and then up again.
(fileProGI only) #720
No confirmation was asked for when deleting formats in ddir/dprodir.
(All) #773
When accessing BLOB/MEMO fields from lookup files, it was possible
for the data to get corrupted.
(All) #774
Under certain conditions, re-executing a fuzzy browse lookup could
cause filePro to crash.