I’m facing a peculiar issue with the CSV writer node. Although the output is in CSV format, when I upload it to the Salvadoran tax entity’s website, it indicates that the format is incorrect. Interestingly, if I save the same file as MS-DOS format, it gets recognized without any modifications. I also observed that copying the cell format from a previously submitted file, without changing the format, makes it readable by the system. I’ve tried all types of encoding to no avail. I’m curious to know if anyone else has experienced similar format-related problems.
Hi @Jeyrell_Sr , because of your mention of ms-dos, my immediate thoughts are that this is some kind of line terminator issue. What OS are you running on?
What did you mean by “copying the cell format from a previously submitted file”?
ie What " cell format" are you referring to, with respect to a csv file?
Apart from character encoding, typically CSV file formats differ according to delimiters, whether elements are in quotes, and the line terminator. Additionally internationalisation of the data could affect whether it is considered valid (eg whether the decimal separator is a comma or a period/point).
Thank you for your prompt response. I’m currently using Windows 10 Enterprise. Regarding the “cell format” question, in the past, I used to perform this process in Excel and saving it as a CSV file never caused any issues. However, now I’m encountering a problem when trying to directly load the CSV document provided by Knime—it states that the format is incorrect.
To address this, I initially opened the previous file and compared the results. Upon finding them identical, I used Excel’s “copy format” option and applied it to my Knime data, then saved the file as CSV, which resolved the issue. Additionally, I experimented with saving the file in another format like ms-dos, and the government page read it perfectly.
I understand that creating a CSV file doesn’t involve a special format, but the output from Knime seems to trigger an error. Yes, I’ve followed all the previous formatting guidelines to ensure there are no special characters in the data. What’s peculiar is that we don’t encounter issues with CSV files for other processes—it’s specifically with this country, El Salvador.
Hi @Jeyrell_Sr thanks for the additional info, Is it at all possible for you to upload an example csv file that does work and one that gets rejected (with any personally indentifying/sensitive info modified). Just a couple of lines from each might be useful. Is the Excel version adding/not including double quotes or using tabs instead of commas? As you say, it sounds like the issue is with the specific recipient, but maybe it is that others are more flexible. I take it that El Salvador’s required file format isn’t documented anywhere? Is this a publicly available site?
@Jeyrell_Sr what you could try is use the encoding “CP437” and try that one. This is an extended ASCII dataset.
If you have a CSV file that is working from your Excel installation you could try and import that back into KNIME and see which encoding does best fit that. Or you could provide us with a sample with some dummy data so we could investigate.
3 Likes
Dear mlauber71 and takbb,
I wanted to express my sincere gratitude for your invaluable assistance. After trying various options, I found that mlauber71’s suggestion with the CP437 format worked perfectly. Now I can read the file without any need for further manipulation.
Thank you both for your expertise and willingness to help. Your contributions have made a significant difference, and I truly appreciate it.
3 Likes
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.