Please folks, I am in panic now.... close to a deadline and I have a show-stopper.
I have made a component that uses an ABL socket to download a document from a Tomcat server. It used to work great and I was happy.
But now, the component needs to be used in an ABL session that is using the "-cpinternal utf-8" session parameter. The socket fails now.
I can't run the app without "-cpinternal utf-8" but I really really need the socket component to work. I don't know what to do.
I was hoping that somewhere I can convert data from utf-8 to whatever or the other way around, to make the program work again, but I don't know how. Any ideas, please??
The socket receives data in memptr p_Data.
The data is appended to RAW variable with this statement:
put-bytes(BinaryMessageFragment, LENGTH(BinaryMessageFragment, "RAW") + 1) = p_Data.
To get the HTTP header I try to read as much as possible of this RAW thing into a LONCHAR variable, like this:
StringMessageFragment = GET-STRING(BinaryMessageFragment, 1).
This statement gives error
** Unable to update Field. (142)
Beers for help!
Jurjen.
Don't copy the data into a raw varaible from the memptr and then to the longchar. Instead use copy-lob statement to copy the memptr data directly into the longchar. if you already know ahead of time that the http request is returning utf-8 encoded bytes, just specify that on the copy-lob statement and progress will decode the bytes properly. If the data is longer then the normal 8k that is buffered by the sockets in ABL, then use the "overlay at" options.
Something like this:
define variable p_data as memptr no-undo.
...
define variable utfdata as longchar no-undo.
copy-lob from p_data to utfdata overlay at length(utfdata )convert source codepage "utf-8".
Thanks Matthew!
Problem solved!
Although I could not really use your suggestion it inspired me to understand that StringMessageFragment=get-string(rawvariable) tries an automatic codepage conversion, but fails.
After a bunch of experiments I decided to define variable StringMessageFragment as a simple oldfashioned CHARACTER instead of a fancy LONGCHAR. No automatic codepageconversion and no problem anymore :-)
I can get away with this because the HTTP response is a binary file (the socket receives a PDF file that was just created by Jasper Reports). The binary stream is chunked. The StringMessageFragment is only there to read the http header and the little pieces of text between the binary chunks. All those pieces are short enough for a simple character variable, no need for a longchar.
Now perhaps I should test with a very long non-binary non-chunked output to see if the character variable overflows, but for now I am very happy.