Stephan van Hulst wrote:Why?
Please always tell us the full details; if you give incomplete details you will get the answer to the wrong question. Which has happened here. Nobody is asking you for a file with CRLF. Since methods like readLine() remove the line end sequence anyway, you cannot tell which line end sequence a line uses. Also, a look at the dcumentation for readLine() should tell you that the line end is a red herring.Puspender Tanwar wrote:Actually I am importing the CSV file to oracle DB using Oracle SQL Loader. . . .
Are you sure about that?Puspender Tanwar wrote:. . . Now I have two CSV having exactly same records
Doesn't that error message give you any hints?. . . second enclosure string not present . . .
I thought earlier that the line ends were a red herribng.So I thought that for CRLF if passing "str '\r\n'" works, than passing the "str '\n'" for LF should work but that's not the case.
Campbell Ritchie wrote:Are you sure about that?
Campbell Ritchie wrote:Doesn't that error message give you any hints?
Liutauras Vilda wrote:Does header have any significance in your application? They aren't same.
Campbell Ritchie wrote:Thank you for posting the text; I did a diff and the only difference is that the headings are in UPPER CASE in one file and lower case in the other. You have already confirmed that doesn't matter, since SQL is case‑insensitive. In view of the triple quote mark in line 4, I am surprised that either file can be correctly parsed into SQL.
I told you to look at the documentation for readLine() and that it removes the line ends, so LF versus CRLF is still a red herring.
Liutauras Vilda wrote:Open that second file (which doesn't load) in notepad++ or other editor and change manually those line endings and please verify to us, that problem indeed is that.
It is taking too long to debug all that stuff.
Liutauras Vilda wrote:And then you end up with 2 and 3rd line records which need to be in sync with first file, meaning have LF, which you can using regular expression change too.
Liutauras Vilda wrote:After that, try to load your version with all CRLF's and tell us what happens.
Liutauras Vilda wrote:After that, try to load your version with all CRLF's and tell us what happens.
Puspender Tanwar wrote:"5002800000MMzJUAA1","false","00001000","Per customer-""
The client is now thinking of buying vs remodeling - I'll keep you posted!
"""
got skipped and gone to the badFile.bad
Liutauras Vilda wrote:Alright, clear what is that bit. So the lines 2 and 3 and 4 are actually 1 record, and those excessive quotes are escaping some quotes in order to have sentence enclosed in quotes (this is what I said at the beginning), so after all, it has 4 columns too and this record ends with CRLF (line 4) as every other record.
Why are you writing that record on 3 separate lines?
Puspender Tanwar wrote:I am not writing these records, I am using the Salesforce.com Api and I get the data in this format only(the incorrect file).
Puspender Tanwar wrote:I am not supposed to change these multiline records to single line
On Windows NT, if no terminator_string is specified, then SQL*Loader uses either \n or \r\n as the record terminator, depending on which one it finds first in the datafile. This means that if you know that one or more records in your datafile has \n embedded in a field, but you want \r\n to be used as the record terminator, you must specify it.
Dave Tolls wrote:So, it's the continueif.
For the version with LF as the record terminator, does the in-record new line always come out as CRLF?
If so, how about trying CR ('\r') as the CONTINUEIF LAST instaed of the double quotes?
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |