Large Data Editor : CR/LF problem

[Jonathan Taylor]

Version : 6.0.5.926

the large data editor seems to misinterpret a Unix-style end of line terminator (one character - CHR(10) - LF) as a Windows/DOS end of line terminator (two characters - CHR(10)||CHR(13) CR/LF).

create table eol_test (clb clob,vc2 VARCHAR2(20));

insert into eol_test values ('abc'||CHR(10)||'def','abc'||CHR(10)||'def'); --Unix EOL

SQL> select dbms_lob.getlength(clb) clb_len
2 ,clb
3 , length(vc2) vc2_len
4 ,vc2
5 from eol_test
6 ;

CLB_LEN CLB VC2_LEN VC2
---------- -------------------------------------------------------------------------------- ---------- --------------------
7 abc 7 abc
def def

This gives the correct results.

However, when the CLB and VC2 fields are inspected in the Large Data Editor, the length is reported as 8. Looking in the "Hex" tab reveals two characters - OD 0A - these are the DOS CR/LF characters.

 

[Marco Kalter]

This is indeed a known restriction. On Windows you will see CR/LF pairs.

 

[Andy Postnikov]

Why should i see something other then stored in DB? Can you show a right values but ask or optionize when saving data!

I've posted a reply in CLOB CR/LF

 

[Magnus Waldemark]

This problem still exists in version 7.1.4.1389. Why can't this problem be corrected? My guess is that you convert single occurances of chr(13) or chr(10) to chr(13)+chr(10) to show linebreaks correctly in the Text-tab. Then you convert that text instead of the text from the db to the Hex Tab.

 

[Claus Pedersen]

The problem is still present in 8.0.1

Could this issue please be given a high bug fix priority? I beleive it has been a bug ever since the large data editor was introduced for the first time? More than 5 years?

The large data editor is quite useless for serious debugging, editing etc. in production environments, as not even the hex editor will always show the actual data.