# 5.0.14 Release Notes

(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.