UTL_FILE, Extra CRFL's, possible OS interpretation problem.

Question

Greetings,
DISCLAIMER:
I am an oracle noob so if I make a mistake in forum etiquette or have not checked all available documentation or have made an assumption that is incorrect ( or noobish ) or am unaware of a tool better suited to the task I am trying to accomplish..
Please don’t flame me, I am learning. Give me constructive replies and I will learn, I promise.
My environment: 10G XE DB running on Server 2k3. Developing in SQLDEV 1.54
I am attempting to dump the contents of a CLOB to a file on the OS disc. Due to formatting restrictions, the contents of the file written to disc must be EXACTLY the contents of the CLOB, character per-per character, verbatim.
Here is an example anon block that will give you the essentials of the way I am attempting to accomplish this:
DECLARE
l_clob CLOB ;
l_output_file utl_file.file_type;
BEGIN
l_clob := 'Hello my name is George!' || chr(13) || chr(10) ;
l_clob:= l_clob || 'Would you like to play a game?' || chr(13) || chr(10);
l_clob := l_clob || 'It will be fun, I promise..' || chr(13) || chr(10);
dbms_output.put_line( dbms_lob.getlength(l_clob));
l_output_file := utl_file.fopen( TEST_DIR' , 'test.txt' ,'W', max_linesize=> 32767 );
utl_file.put( l_output_file , l_clob );
utl_file.fflush( l_output_file);
utl_file.fclose( l_output_file );
utl_file.fclose_all;
END;
Here you can see where I put a few lines into my clob, I manually append the CRLF using the CHR function, since I cant accurately reproduce a non-printable character in a string value. This is important because the Clob I am attempting to write to disc contains CRLF’s as part of its data, these must be preserved. Also note that I am writing this to the file using utl_file.PUT not PUT_LINE, again, because the disk file must be the clob verbatim, I cant use put_line because it adds a “new line character” at the end of the data it writes.
Ignore the DMBS_OUTPUT line , I will get back to that in a bit.
I execute this bit of code and get a file text.txt. What I expected to see was:
“'Hello my name is George!
Would you like to play a game?
'It will be fun, I promise..”
What I actually got was:
!http://i594.photobucket.com/albums/tt22/GargleSpam/Temp001.jpg!
Looking at this in notepad++ we can expose the non-printable chars:
!http://i594.photobucket.com/albums/tt22/GargleSpam/Temp002.jpg!
Using notepad ++ we can see that an extra CR ( CHR(13)) has been pre-pended to the CRLF. We can confirm this is not an artifact of viewing this in notepad by looking at the file size of the output file and comparing it to the size of the clob.
The DBMS_OUTPUT line indicates ( in my test case) clob size of 87 characters. If you take the time to count you will see this is correct. 81 printable characters that we see, and the 6 non-printable chars to accomplish the CRLF’s.
However if we look at the file size:
!http://i594.photobucket.com/albums/tt22/GargleSpam/Temp003.jpg!
So that’s 87 + our 3 “ninja ” CR’s.
For my purposes this is a deal-breaking problem. The contents of my output file must be exactly the contents of my clob, byte for byte. So this extra CR is a big big problem.
Where is it coming from? I started thinking about the “new line character” that the PUT_LINE procedure uses and, had a hunch that perhaps since the DB is OS independent, it might be passing one of the non-printable chars to the OS as “new line” and letting the os worry about what that means on disk. With that in mind I did some further testing:
DECLARE
l_clob CLOB ;
l_output_file utl_file.file_type;
BEGIN
l_clob := 'Incoming lf->'|| chr(10) ;
l_clob:= l_clob || 'Incoming cr->' || chr(13);
clob:= lclob || 'Incoming CRLF->' || chr(13) || chr(10);
l_output_file := utl_file.fopen( TEST_DIR' , 'test.txt' ,'W', max_linesize=> 32767 );
utl_file.put( l_output_file , l_clob );
utl_file.fflush( l_output_file);
utl_file.fclose( l_output_file );
utl_file.fclose_all;
END;
This code results in:
!http://i594.photobucket.com/albums/tt22/GargleSpam/Temp004.jpg!
Looking at this it becomes obvious that the CHR(10) is being written to disc as TWO characters ( CR LF). So my assumption must be correct, that the DB is passing CHR(10) to the OS as “newline” and the OS ( Windows in my case ) is interpreting this as ‘CRLF.’
This makes sense since it seems to be widely known ( though not to me , I am shaky on this part ) that “newline” in unix is just CHR(10), and in windows its CHR(10)||CHR(13).
So I seem to have isolated my problem. Now finally my question.. How to I get around this?
Google searches and searches on this forum yeilded only marginal help, something about passing this file through an FTP server.. ?. The only marginal help was in post # 3298335. Nothing that really answers my question though.
Is there a setting my DBA can set to change this behavior? Is there a different way ( PLSQL) to write the file that might mitigate this? Don’t say put the DB on unix, that’s not an option.
Let me know what you think…
-VAF

Answer 1

Hi,
Also you should check that the directory name is enclosed between '. TEST_DIR is an Oracle directory object that maps a real directory path in the filesystem (check privileges).
Like:
DECLARE
    l_clob CLOB;
    l_output_file utl_file.file_type;
BEGIN
    l_clob := 'Hello my name is George!' || CHR(13) || CHR(10);
    l_clob := l_clob || 'Would you like to play a game?' || CHR(13) || CHR(10);
    l_clob := l_clob || 'It will be fun, I promise..' || CHR(13) || CHR(10);
    dbms_output.put_line(dbms_lob.getlength(l_clob));
    l_output_file := utl_file.fopen('TEST_DIR', 'test.txt', ' W', max_linesize => 32767);
    utl_file.put(l_output_file, l_clob);
    utl_file.fflush(l_output_file);
    utl_file.fclose(l_output_file);
END;Tip: to post formatted code you must enclose it between {noformat}{noformat} tags (start and end tags are the same).
Regards,