I have a LONGCHAR that disappears (becomes null) when passed into a procedure. See below. Anyone have any idea why the LONGCHAR is fine on one side of the procedure call and becomes blank on the other?
/* FILE Send.p */
DEFINE TEMP-TABLE TT_Markup XML-NODE-NAME "Markup"
FIELD ManualDisplayOrder AS INTEGER INIT 1 XML-NODE-TYPE "ATTRIBUTE".
DEFINE DATASET DS_Root XML-NODE-NAME "Root" FOR TT_Markup.
DATASET DS_Root:EMPTY-DATASET().
/* Write empty dataset clob */
DEFINE VARIABLE v_Clob AS LONGCHAR NO-UNDO INIT ?.
DATASET DS_Root:WRITE-XML ("LONGCHAR", v_Clob, TRUE).
COPY-LOB v_Clob TO FILE "_before.xml".
/* GO FOR IT */
LOG-MANAGER:WRITE-MESSAGE("{&FILE-NAME} {&LINE-NUMBER} RUN " ).
DEFINE VARIABLE v_Error AS CHARACTER NO-UNDO.
RUN aaa/ClobTest/Receive.p (
v_Clob,
OUTPUT v_Error).
LOG-MANAGER:WRITE-MESSAGE("{&FILE-NAME} {&LINE-NUMBER} DONE " ).
/* DONE */
MESSAGE "Error was: " v_Error.
/* FILE Receive.p */
DEFINE INPUT PARAMETER p_ClobSerializerData AS LONGCHAR NO-UNDO.
DEFINE OUTPUT PARAMETER p_Error AS CHARACTER NO-UNDO.
p_Error = "{&FILE-NAME}: Unexpected Error. ".
/*
COPY-LOB p_ClobSerializerData TO FILE "_after.xml".
*/
IF p_ClobSerializerData = ? THEN
DO:
LOG-MANAGER:WRITE-MESSAGE("{&FILE-NAME} {&LINE-NUMBER} Bad " ).
p_Error = "Invalid clob data.".
RETURN.
END.
LOG-MANAGER:WRITE-MESSAGE("{&FILE-NAME} {&LINE-NUMBER} GOOD " ).
p_Error = "".
Basically we get an error message that we shouldn't be getting. Here is the process that sends the data:
Here is the one that should be receiving it:
No, it's not known, so could you please report it to Technical Support?
I believe there is a bug here. Remove the INIT ? from the LONGCHAR definition and it should work as you expect.
Thanks Fernando.
Is this one that you had seen before? What is the KB for that?
I can confirm that behavior for OE 10 and 11.
Looks to me that the LONGCHAR length information is not correctly handled. It never get correctly updated and keeps ?. Even so the string itself gets filled and can be exported.
While methods WRITE-XML and COPY-LOB not really care about the string length the function LENGTH and all string compares do.
DEFINE TEMP-TABLE TT_Markup XML-NODE-NAME "Markup"
FIELD ManualDisplayOrder AS INTEGER INIT 1 XML-NODE-TYPE "ATTRIBUTE".
DEFINE DATASET DS_Root XML-NODE-NAME "Root" FOR TT_Markup.
DEFINE VARIABLE v_Clob AS LONGCHAR NO-UNDO init ?. /* remove init ? */
DATASET DS_Root:EMPTY-DATASET().
message length (v_clob).
DATASET DS_Root:WRITE-XML ("LONGCHAR", v_Clob, true).
COPY-LOB v_Clob TO FILE "c:\temp\_before.xml".
message length (v_clob).
No, it's not known, so could you please report it to Technical Support?
I wonder why I'm the first to report it? I suppose it is still pretty unusual for LONGCHAR's to be used by normal ABL programmers (as opposed to CHARACTER). AFAIK there is no other way to handle CLOB's coming in and out of the database. Maybe those are still not used very frequently either.
What is really odd to me is that the LONGCHAR works fine on one side of the procedure call, but after it comes over to the receiving procedure, the exact same LONGCHAR (supposedly passed by value ???) is totally different. It is particularly scary for database developers to have to second-guess if/when the data they are passing around will disappear on them. Even a ABL STOP condition, along with the death of the client would be preferable to disappearing data.
I was thinking it was a new mechanism for parameter passing in ABL: BY value, BY reference, BY disappearing ;)
Hi dbeavon,
We use longchars a lot. Also combined with CLOB's. We only never use initial values for Longchars.
Groeten,