Strange NUL value occurrence in some fields

[Joe Chasan]

How does the data get into these fields exactly?

I think I've seen this when pulling in garbage from an import file.

How to fix?

First, confirm if filePro truly sees this as null - maybe a 
process table that checks for chr("0") with contains command.

*If* that works, then I think you can have filePro fix it.

With newer filepro (!!!), you can use replace command, but I think yours
is too old for that.   Not sure about xlate, I know xlate would not pull
chr("0") out originally, perhaps it was fixed in more recent versions, but
again, you're on 5.7.

Failing that - and this is untested, if you don't have replace command, it's
messy, but I think you could make a loop with the mid command, checking each 
character for non-null-character and rebuild field: if non-null, stick it 
into a new temp field, then when finished looping through the field, copy 
temp field back to real.

And the box characters are how chr("0") through chr("10") display on
a filepro screen, whether in data, show, msgbox, errorbox, etc.

-joe

On Mon, Feb 02, 2026 at 05:06:34PM -0600, James Flanagan via Filepro-list wrote:
> FreeBSD 12.2
> Filepro 5.7.00.09D4
> 
> I have found a few occurrences of what appeared to be data corruption in a few fields in my database.  
> 
> In the fields where this had occurred, the screen with those field values would appear to show an _upper left hand corner line_ where there should have otherwise been an ascii letter or number, as the edit type for the field is (6,allup).  
> 
> http://flantec.com/images/filepro1.png
> 
> I have examined the keyfile in a hex editor, and the 6 characters for this field, represented on the far right as ____, have ascii values as _00_ for each character, the NUL character.  As you see both above and below the 00_s, every other _blank_ character in each field is represented by _20_, the standard space character.  No matter if you blank out a field manually, or send a lookup(8)=_ _ type of command, the blank field will always be made of _20_ ascii characters.  
> 
> http://flantec.com/images/filepro2.png
> 
> In addition, this only affects this field in question, without affecting the fields either prior or after, which I would assume rules out any intermittent failing drive.  Not to mention, this corruption to the field appears to happen on the original save of the record, and not as the result of any subsequent edit to the record.
> 
> So, my question is does anyone have any idea what could possibly be happening here, resulting in an ascii _00_ character, and even more importantly, how to possibly prevent it?  Thank you very much in advance...
> 
> 
> 
> 
> James Flanagan
> Flantec.com <http://flantec.com/>
> 
> email:	James at Flantec.com <mailto:James at Flantec.com>
> mobile:	760-458-8498
> home: 	219-221-6219
> text:		7604588498 at txt.att.net <mailto:7604588498 at txt.att.net>
> 
> Skype:	Flantec
> ichat:	James at Flantec.com <mailto:James at Flantec.com>	
> 
> home:	1901 Cidermill Road
> 		Michigan City, IN 46360
> 
> _
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20260202/adbff92a/attachment.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: PastedGraphic-1.tiff
> Type: image/tiff
> Size: 19328 bytes
> Desc: not available
> URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20260202/adbff92a/attachment.tiff>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at mailman.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> https://mailman.celestial.com/mailman/listinfo/filepro-list
-joe

--
-Joe Chasan-                           Magnatech Business Systems, Inc.
joe - at - magnatechonline -dot- com   Plainview, NY - USA
https://www.MagnatechOnline.com        Tel.(516) 931-4444
Proud member of iXorg                  Fax.(516) 931-1264