I'm trying to store a PDF file in a BLOB field in database, and then getting it back to a temp directory.
But the restored file contains some differences with the file I stored (adding some characters to the beginning of the file, making the PDF file corrupted) and the application stops with an openedge error !
Here are the lines I use to do it :
COPY-LOB FROM FILE fileName TO ged.dataFile NO-CONVERT NO-ERROR.
(OpenEdge Release: 11.0.0)
My guess is that OE is prefixing the LOB to FILE copy with BOM characters.
Do the prefixed values look anything like these?
UTF-16 (LE) (U+FEFF)
UTF-16 (LE) (U+FFFE)
UTF-32 (BE) (00 00 FE FF)
UTF-32 (LE) (FF FE 00 00)
Well, in one of my tests, OpenEdge added 4C 00 5C FA to the beginning of my file.
But this can change depending on the file I use... (I also have once 4E 00 5E FA ...)
And it seems that OpenEdge try to make the file the same size, so 4 bytes are missing at the end of the file
What can I do with this ?!
Not even the more obscure character sets use those values for a BOM so I
think that hunch can be eliminated.
BLOBs shouldn't be writing BOMs anyway - but it is the only value I
would expect to ever get prefixed to your data so it was worth asking.
I wonder if this is an address size issue. Do you get the same results
on 32 and 64 bit platforms?
I don't know, I have only 64 bits OS... windows 7 and linux for the database.
are you using a BLOB or CLOB column to store the data file? You should use BLOB.
I actually use Blob data type...
then there may be a bug. we should treat a BLOB as a bag of bits and not modify the data when reading from and writing to files.
I tried the same thing with the same environment i.e., OE 11.0, database on Linux and with client on Win7 64 bit OS. There are no differences.
There have been core COPY-LOB changes in version 11 so I think it makes
sense to report this as a bug.