5.0.13 Release Notes

(SCO only) #???

 

Fields with extended-ASCII characters ( >=128 ) might not compare

correctly.

 

(All) #653

 

Browse lookups with only a single line could crash filePro.

 

(All) #662

 

DLEN() had an undocumented limit of 255 characters on the input

string. The input is now unlimited, and the output is limited

to 4095.

 

(*nix only) #667

 

Some *nix systems prevent a setuid program running with a real uid

of root from executing child processes. The previous workaround

(setting the real uid to "filepro" when running as root) causes

some things (such as printer banner pages) to report "filepro" as

the user.

 

Added "PFROOTFIX=OFF" to turn off the fix for systems that don't

require it.

 

(Native windows) #???

 

@ID will now contain the current user name, up to the first 8 letters.

 

(All) #633

 

If you have a memo with a line so long that it doesn't fit within

the memo editor window, and while in insert mode press Enter near

the top of the memo (to split the line), the program may crash.

 

(All) #???

 

Enhanced the blobfix utility to do a better job at extracting data

from a blob within a corrupted section of the file.

 

(All) #587

 

"lookup - -pw" did not honor the "-w" flag.

 

(All) #656

 

FORM command within a CALL NOAUTO'ed processing table would use

fields from the automatic table.

 

(Native Windows) #671

 

sitepwd.exe did not work under XP.

 

(All) #668

 

Output formats would not function properly if the height*width

was more than 32K.

 

(All) #672

 

"ddir -k" did not respect the lockfile.

 

(Native Windows) #673

 

p.exe splash screen would fail if the licensee's name contained

a lower-case "z".

 

(Sun and PPC Linux) #675

 

filePro would crash if TERM/PFTERM was set to an entry that

contained a "tc=" value.

 

(All) #674

 

IMPORT/EXPORT using an expression for the filename would not

compile properly in just the right circumstances. (Symptoms

included adding or deleting lines with literal strings would

make the problem go away.)

 

(GI) #644

 

Timing issues caused connections to GIserver over a satellite

link to fail.

 

(GI) #651

 

Prompt buttons were missing with browse lookup windows.

 

(All) #670

 

autoshuf would crash on some systems when adding fields.

 

(All) #676

 

dxmaint would not update the status screen while reading large

sections of deleted records within the file.

 

(All) #680

 

filepro would crash on "-pq" if a printer was defined without

any comment.

 

(All) #682

 

Dummy fields set in @ONCE did not hold their values in @BRKn

and @WGT processing.

 

(All) #690

 

In just the right combination of circumstances (full desription

to come), filePro could crash in the index delete routine.

 

(All) #683

 

System fields didn't push left with "<" on the output form.

 

(All) #700

 

If @ONCE processing makes an assignment to a dummy field that is

not defined in automatic processing, *report may crash.

 

(ODBC) #692

 

In some ODBC data sources, updating a record via high-level ODBC

would cause a nul character to be appended to the data in some

field types.

 

(All) #686

 

MESGBOX/ERROROX with long lines would drop 1 character at the end

of each wrapped line.

 

(All) #695

 

*cabe didn't recognize the new @DV system field.

 

(Native Windows only) #698

 

EXISTS() would return "1" (true) if the specified path included

an existing filename as part of the path. For example, if the

file "c:/filepro/backup.zip" exists, then passing EXISTS() the

name "c:/filepro/backup.zip/map" would return true.

 

(ODBC) #691

 

dprodir would crash attempting to display info on an ODBC file.

 

(fileProGI) #688

 

"MEMO ... EDIT TITLE ..." didn't display the title.

 

(fPSQL) #618

 

fPSQL did not recognize new 4-digit-year system date fields,

nor PFSYSYR4=ON.

 

(Unix xfer) #687

 

The Unix version of xfer did not send screen/output formats

that were longer than the old limit of 14 characters.

 

(All) #661

 

BREAK OFF wasn't honored within a browse lookup.

 

(SCO only) #677

 

If a file exceeded the ulimit file size, filePro would crash with

a SIGXFSZ signal, rather than give the "file too large" error.