I know that Samuel had suggested on a slightly related topic that I look into the cSeqFileHelper.pkg
But I don't see how it fits into reading and writing BINARY files.
For example, in DF19.0, I have this code to read a file into Binary Fields (I've condensed it here for the illustration)
Code:
Direct_Input channel iChIn ('BINARY:'+(ToANSI(sFile)))
Repeat
Set_Channel_Position iChIn to (iPos)
If ((iLength-iPos)<iMaxChunkSize) Move (iLength-iPos) to iReadLength
Else Move iMaxChunkSize to iReadLength
Read_Block channel iChIn MyDoc iReadLength
Clear R1BIN
Reread
Move iNumber to R1BIN.FILEREP
Move (SYSTEM.LAST_FBINARY+1) to R1BIN.Number
Move (SYSTEM.LAST_FBINARY+1) to SYSTEM.LAST_FBINARY
//Move MyDoc to FBINARY.CONTENT
Set_Field_Value R1BIN.File_Number (RefTable(R1BIN.Content)) to MyDoc
Move iReadLength to R1BIN.LEngth
SaveRecord SYSTEM R1BIN
Unlock
Move (iPos+iReadLength) to iPos
Until (iPos>=iLength)
And then to pump the file back into existance, I use this code:
Code:
Direct_Output channel iChOut ('BINARY:'+sPath+(ToANSI(sFile)))
Clear R1BIN
Move iNumber to R1BIN.FILEREP
Move 0 to R1BIN.Number
Repeat
Find gt R1BIN by Index.2
[not Found] Move 'done' to sStatus
[Found] Begin
If (R1BIN.filerep<>iNumber) Move 'done' to sStatus
Else Begin
Get_Field_Value R1BIN.File_Number (RefTable(R1BIN.content)) to MyDoc
Write channel iChOut MyDoc
End
End
Until (sStatus='done')
Both work flawless in DF19.0 but not in DF20.0, and I know that it has to do with OEM vs ANSI vs UTF8,
But because the field being written to a field (R1Bin.Content) which is of type BINARY, why does that even matter?
To me Binary is Binary, and the character set when doing Direct_input or Direct_Output when BINARY: is indicated should be that OEM/UTF8/ANSI shouldn't come into play.
Am I out in left field on this one, or do you feel the same? If you agree with me, then this should be logged as a bug in DF20.