Page 1 of 1
CSV restored from BLOB cannot be read by program
Posted: Wed Aug 09, 2023 12:56 pm
by gracehsu
I think the problem is that the CSV was CCSID 37 when it went in, but when it got restored it's CCSID 65535. At the moment I've got the program changing the CCSID back to 37 when it's a got a CSV or TXT extension... at this point I'm contemplating capturing the CCSID as it goes in so that I know what to change the CCSID as it comes out. is there a better way to do this?
Re: CSV restored from BLOB cannot be read by program
Posted: Wed Aug 09, 2023 3:51 pm
by Scott Klement
A BLOB is meant for binary data. (It stands for
Binary
Large
OBject)
Your complaint seems to be that the BLOB is being restored as a binary file rather than a text file. CCSID 37 makes no sense in the context of a binary file.
I suppose the easiest thing to do is
Code: Select all
CHGATR OBJ('/path/to/file.csv') ATR(*CCSID) VALUE(37)
But, a more "proper" solution might be to use a CLOB rather than a BLOB. For example, use a Unicode CCSID like 1208. When loading the text into the CLOB, make sure it translates properly to Unicode. When writing it to a file, it'll be written as Unicode, but if the program is opening it correctly, that program will instruct it to translate to whatever CCSID the program needs it in, and since it's unicode it should support it properly.
Then it won't matter what the CCSID of the input source is (provided that it's text) it will be stored as unicode after it is imported.
Re: CSV restored from BLOB cannot be read by program
Posted: Tue Aug 15, 2023 12:53 pm
by gracehsu
Thanks for the response. I was hoping I missed something. Alas, this process needed to be a BLOB as we store PDF's, graphical images like JPG, GIF, and etc in it. I've added a field to store the OG CCSID & added chgAtr to the de-archive program.