Curious how do workbench and the other (have not used that i guess) screw up CSV exports?
Recently tried workbench after a year or 2 again; was enjoying some new features, but the lack of OSX dark theme support is hurting usability, some parts of UI and or texts are simply unreadable. I hope they sort that soon. Workbench is not one of many that supports connections over ssh native, which is nice as i hope non of the folks here run interfacing databases :). The performance analyses tab is quite neat, saves me a lot of manual query logging and plowing through that to find bad queries.
I'm not sure about HeidiSQL but I've had great luck with MySQL database exports using PHPStorm. I think PHPStorm essentially has DataGrip built-in:
https://www.jetbrains.com/datagrip/
After having trouble with workbench, Using PHPStorm I was able to export a whole database to a file per table in one go and both TSV/CSV are supported. I found my resultant CSV files to be reliably escaped.
Though I'm not familiar with the CSV export of those two tools, I've had adventures in CSV parsing from other tools. How do they screw it up? Is there a canonical "correct" way defined somewhere?
I cannot remember exactly how they each screw it up, but the issues I have had are, but not limited to,
a) truncation of data
b) removal of line breaks
c) not escaping enclosing values, ex. " as ""
d) using \n or other values in place of actual line breaks or tabs
e) using \N for NULL values (which isn't too bad, but it would be nice to be able to configure this)
f) in general not complying with https://tools.ietf.org/html/rfc4180
I wonder what percentage of CSV represented data 1) passes through a spreadsheet at some point from data source to final data consumption and 2) how much of that spreadsheet action is specifically MS Excel.
You're right, there is no standard that I'm aware of, though the answer to those first two questions could well be a proxy for a de facto standard in practice.
