CSV restored from BLOB cannot be read by program

[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?

[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.

[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.