Kbase P159463: COPY-LOB truncates CLOB data copying to a LONGCHAR
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
01/02/2010 |
|
Status: Unverified
SYMPTOM(s):
COPY-LOB truncates CLOB data copying to a LONGCHAR
ASCII data stored in a database CLOB is truncated with the statement:
COPY-LOB <clob field> to <longchar>.
Only part of the data is copied. For example a clob containg the string "true" results in "tr".
The following code will illustrate the problem in a session started with -cpinternal UTF-8.
DEF VAR clo AS LONGCHAR NO-UNDO.
FIND FIRST <table> NO-LOCK NO-ERROR.
IF AVAIL <table> THEN DO:
COPY-LOB <table>.<CLOBfield> TO clo.
MESSAGE STRING (clo) SKIP
LENGTH(<table>.<CLOBfield>, "character") SKIP
LENGTH(<table>.<CLOBfield>, "raw") SKIP
LENGTH(clo, "character") SKIP
LENGTH(clo, "raw") SKIP
SESSION:CPINTERNAL
DBCODEPAGE(1)
VIEW-AS ALERT-BOX INFO BUTTONS OK.
END.
FACT(s) (Environment):
The client session is started with -cpinternal UTF-8.
The database code page and CLOB field code page is iso8859-1.
The problem cannot be reproduced in OpenEdge 10.2B.
Windows
OpenEdge 10.2A
CAUSE:
The COPY-LOB statement is truncating the data as it is copied to the blob filed. The issue has been resolved in later versions of OpenEdge.
FIX:
Upgrade to OpenEdge 10.2B or later.
Or as a work around specify the length of the copy operation in the COPY-LOB statement. For example:
COPY-LOB <table>.<CLOBfield> FOR LENGTH(<table>.<CLOBfield>) TO clo.