Greasy Fork

When is a csv not a csv?

I did get import to read my 10-11 CSV backup, but now (on a different Firefox/OS combo that the one I've been yammering about elsewhere), when I read it into LibreCalc there were no delimiters so all I had was 1 column for every HIT.

Reading it into gedit, it appears to be tab separated ...

BTW, I was a little surprised to see all those records dumped to my screen as well ...

Dumping to screen maybe uses tabs, not the comma separated you want in the export file ...

Yeah, it's tab delimited. Most spreadsheet applications should be able to auto-detect it, but even if it doesn't, there's always a way to specify the delimiter.

Dumping to screen maybe uses tabs, not the comma separated you want in the export file ...

I don't understand what you mean.

Please don't redefine what a .csv is. Not nice/kosher ... whatever word you want to use. Just say no. The C is for comma! Not everyone uses MSFT products!

Frankly, I don't want see thousands of records dumped to my Hit Database MK. II section of the Dashboard page (or filling up some memory queue somewhere waiting to be dumped) At the very least it dumps some number of lines that just uglies up my page and then I have to hit the clear button to restore it normal. Waste of my time. I will verify the file in other ways, sch as its size compared to others I've saved, or reading it into another program to make sure the data is usable and complete to my expectations.

It just seemed like that you took the "easy way out" by using the same format so you could display it in the Hit Database MK. II section of the Dashboard page, as well as write it to the file.

BTW, I'm not trying to be critical or unappreicative. You did a lot of work and made some great improvements. Thank you!

Oh I thought I had taken that out prior to coming out of beta. It isn't supposed to display anything in the results section after an export. I'll remove it.
Edit: It's been removed as of 1.0.009.

CSV has evolved beyond being strictly for commas. It has absolutely nothing to do with Microsoft whatsoever. Take SQLite for example: its default delimiter is a pipe, IIRC. In popular usage, the CSV term is used to denote other similar formats with a variety of different field delimiters. I have no interest in arguing over semantic terminology or its purity.

Fine. The MSFT reference had to do you remark about "most spreadsheet applications" As a Linux user I get a little tired of having what works on MSFT being the be all and end all and everyone expected to get in line with what they do. I can change the default delimiter on my spreadsheet program (which looks I presume at the csv file suffix), but I never had too in the past.

BUT....

it FAILS reading it even if you specify tab as the delimiter, and once again it has to do with Approver comments containing tabs from time to time (like my issue previously about them possibly containing new lines. These things are strings and need to be in quotes. And the scanners that read them in need to realize they're strings and read to the end of the string.

If you look at the csv files produced by the thing you are "replacing," they look like this:

"3BC9H1KCYUDPJH10IDA9S534EXKWYX","2015-02-11","p9r","A3HV8QI42N179B","Transcribe data",0.02,"Paid","",
"3S8A4GJRD334CI6TE9BGDVNTAO96VS","2015-02-12","Claire Gillan","A1747RL71SV75E",""Make Choices for Money"",2.00,"Paid","",

EVERY field is quoted ... maybe because it was easier ... I don't know. Remember that AMT has changed field orders (or more accurately split one up I think into two of them) in the past, so maybe quoting every field was simpler.

Automatically assuming "most spreadsheet applications" means "it was only tested on Microsoft products so it should apply to everything else" is an entirely false assumption and not really a problem I can help you with.

I have an internal version in which I'm improving and testing the parser to better accommodate special characters like the ones you've mentioned. It'll be rolled out when it's ready.