Easily find issues by searching: #<Issue ID>
Example: #1832
| Dev |
|
| QA | swissarmyknife(*) |
| Priority | Critical |
| Complexity | Unknown |
| Component | Tools - Import Tool |
| Version | 14.0 |
Does not occur in v13.0
Does occur in v14.0
likely related to IID 9352
If the last comment in that issue was actually incorporated into that fix, it is the likely culprit.
Generate a CSV file that uses only CR (carriage returns) as EOL
1. in OSX open the Import tool and select the file
2. Attempt to import the file. Notice that none of its rows appear.
3. You can view the file in an editor that allows you to see the CR at EOL and see that its data is in separate rows
see attached screenshots and a sample CSV
|
|
161 KB
|
|
252 KB
|
103 B
|
|
92 B
|
|
143 B
|
|
8 KB
|
|
167 KB
|
|
213 KB
|
|
218 KB
| Field | Old Value | New Value |
|---|---|---|
| Dev Assignee | SachinPrakash (Sachin Prakash) | funfun (Fun Fun) |
This has something to do with the changes made by issue 9352. Prior to 9352 fix, either CR or LF is treated as a record separator; the change made by 9352 only accepts LF as a record separator. Hence, in the current ADS implementation, if a CSV file uses CR as the record separator, then the entire file is read in as a single record; if the 'First row contains column names' field is checked, then nothing will be displayed in the 'Sample File Columns' panel; if the 'First row contains column names' is unchecked, the one record is displayed in the 'Sample File Columns' panel.
@funfun: we need to change the behavior to do the following:
- If user has chosen Windows style line endings (CR/LF):
- If user has chosen Linux style line endings (LF):
The above should match how v13 behaves
@funfun: we need to change the behavior to do the following:
- If user has chosen Windows style line endings (CR/LF):
- If user has chosen Linux style line endings (LF):
The above should match how v13 behaves
| Field | Old Value | New Value |
|---|---|---|
| Priority | Low | Critical |
I've attached an additional file that has mixed CR and CRLF in the same csv
for illustrative purposes I've added screenshots showing:
a cr only file side by side of v13 and v14 - unix style eol setting
a cr and crlf mixed file side by side of v13 and v14 - unix style eol setting
a cr and crlf mixed file side by side of v13 and v14 - windows style eol setting
an image indicating the file with mixed CR and CRLF eol
I've attached an additional file that has mixed CR and CRLF in the same csv
for illustrative purposes I've added screenshots showing:
a cr only file side by side of v13 and v14 - unix style eol setting
a cr and crlf mixed file side by side of v13 and v14 - unix style eol setting
a cr and crlf mixed file side by side of v13 and v14 - windows style eol setting
an image indicating the file with mixed CR and CRLF eol
| Field | Old Value | New Value |
|---|---|---|
| Fixed Build | 14.0.0-2/15.0.0-dev-23 | |
| Resolution | Fixed | |
| Resolved Date | Oct 9, 2013 10:28 PM | |
| Status | New | Resolved |
Fixed - either CR or LF can be used as a record separator
14.0 - SVN r34377/14.0.0-2
trunk - SVN r34380/15.0.0-dev-23
Notes:
(1) v14 CSV filing parsing should behave the same way as v13 does, i.e., either CR or LF can be used as a record separator.
(2) In ADS, platform EOF specified in the Import dialog is not passed down to the low level object that is responsible for CSV file parsing.
(3) Also re-tested issue 9352 to ensure blanks are skipped. Now, 2 consecutive CRs also imply a blank line because CR is interpreted as a record separator. Please retest 9352 in your environment, too.
Fixed - either CR or LF can be used as a record separator
14.0 - SVN r34377/14.0.0-2
trunk - SVN r34380/15.0.0-dev-23
Notes:
(1) v14 CSV filing parsing should behave the same way as v13 does, i.e., either CR or LF can be used as a record separator.
(2) In ADS, platform EOF specified in the Import dialog is not passed down to the low level object that is responsible for CSV file parsing.
(3) Also re-tested issue 9352 to ensure blanks are skipped. Now, 2 consecutive CRs also imply a blank line because CR is interpreted as a record separator. Please retest 9352 in your environment, too.
| Field | Old Value | New Value |
|---|---|---|
| Status | Resolved | Verified |
| Field | Old Value | New Value |
|---|---|---|
| Status | Verified | Closed |
Issue #10368 |
| Closed |
| Fixed |
| Resolved |
Completion |
| No due date |
| Fixed Build 14.0.0-2/15.0.0-dev-23 |
| No time estimate |
1 issue link |
relates to #9352
Issue #9352Delimiter bug on data import |
This has something to do with the changes made by issue 9352. Prior to 9352 fix, either CR or LF is treated as a record separator; the change made by 9352 only accepts LF as a record separator. Hence, in the current ADS implementation, if a CSV file uses CR as the record separator, then the entire file is read in as a single record; if the 'First row contains column names' field is checked, then nothing will be displayed in the 'Sample File Columns' panel; if the 'First row contains column names' is unchecked, the one record is displayed in the 'Sample File Columns' panel.