I face the same issue with 3.5.4.2.
Any known work around?

Confirmed. 

Bodhi Linux
Libo: 3.6.1.2

Workaround: File - Save As again, then you can save with comma or whatever you'd like

Prioritized:

Minor: Doesn't prevent professional quality work, CSV still works fine, just the separation of columns is changed from , to a tab

Low: Not many users affected, easy work around, CSV still works

Still able to reproduce the bug with 4.0.0.2rc. I personally think it's not such a minor issue. I process CSV files with my scripts, now I have to search and replace those damn tabs to commas because LibreOffice messed up my files.

Instead of a workaround I would prefer a fix. It's a shame such a simple file format cannot be handled correctly with LibreOffice.

P.S.: why tabs?? it is called a *comma* separated values file for a reason. Why is the default separator set to tab when saving CSV? It really puzzles me.

Version is the oldest version that we see the issue, we use comments to say that we've confirmed on a newer release. Changing version back.

Also, I heavily disagree that this is a normal bug...normal bug means you are UNABLE to make high quality work, because there is a workaround, you are not prevented from doing so. That being said, I will leave it as normal.

Still broken as on 4.0.0.3 / Win. 
Workaround exists, but still it's a bug - since it corrupts data silently without warnings; and you have to know about it (be hurt once) before you can apply the workaround.

Three separate users who have identified this as a problem - upping priority to medium.

Also I don't think this would be very difficult to fix, adding:

ProposedEasyHack

Seems to be fixed in Master?

I'd like to attempt to fix this problem, seems easy enough for me. :-)

I can't reproduce this in master or 4.0.1

Appearently when I read through the code and looked through the history, there has been no changes to impex.cxx file that manage CSV exporting. I am also unable to reproduce the bug on 4.0.1 as I'm on Linux, but I'm unsure if this apply to Windows as well.

http://cgit.freedesktop.org/libreoffice/core/commit/sc/source/ui/docshell/impex.cxx?h=libreoffice-4-0-1

It seems that I can't reproduce it either (even on files that used to be problematic). This is on Ubuntu 12.10 with Libreoffice 4.0.1.2. Marking as resolved.

This bug is still present in 4.0.1.2 contrary to what I reported earlier.

I also figured out how to reproduce this bug more precisely:

1. Create a CSV file using default CSV delimiters
2. Close the file
3. Re-open the file. At the Text import dialog, if "Separated by Tab" is checked alongside of "comma" (comma being the actual delimiter), after editing and saving the file, the delimiter is converted to TAB.

In other words, it seems that the text import option override the actual field delimiter being used by the file.

Indeed, that's reproducible.

@Tyler:
Do you want to work on it?

It seems the remembered export options' delimiter is overridden by the import options' ones even if those are more than one and then probably just the first encountered is used that happens to be the tab character.

Note that there is no such thing as "the actual field delimiter being used by the file", every delimiter that is checked in the import options is treated as such when encountered in the file, just that in this case there is only a ',' comma delimiter present.

Confirmed on Windows 7 64 bits in 
Stable production for enterprise 4.0.4.2 and several Linux ( Ubuntu 12.10, 13.04 and openSUSE 12.3 and next 13.1)

If one day a user check the import TAB separator option, any file he could save (without going to avdvanced) will have the original separator (,;:whatever) replaced by TAB.

This cause irremediable lost of quality data, expected by enterprise users.
For example, this silent change of separator can cause unexpected crash in a transform chain or corrupted data.

As it was working before, it has to be considered as a bug + regression.

Could someone raise the priority, and also start to fix it.

Please don't update version and please read all the comments as I've already explained this.

Also - sure you can find someone to fix it, the code is there, our volunteers are busy working on a lot of things - if you need this one fixed all the code is Libre (meaning open for you to explore). Patches are welcome

Can this bug be closed as a duplicate of bug #43352 ? They would appear to report the same issue. This one is marked as ProposedEasyHack while the other bug is marked as a regression, target:3.5.0, and is filed against v3.4.3. Both have been closed and re-opened at some point.

*** Bug 43352 has been marked as a duplicate of this bug. ***

Marked the other one as duplicate because this one here has a better description of what is going wrong when, see comment 12

Taking this.

What happens is that from the list of separators specified during import the first encountered is used, which happens to be Tab (or semicolon if checked) in this case. We can't do much else than applying some heuristic what separator to pick, i.e. weigh the separators present in the order comma, tab, semicolon, space and other.

If you know the separator used in the file select only that during import to be sure.

Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5af6437f6b602773fb76dca76be1fc079d93c922

resolved fdo#53449 weight given separators to pick one for output



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.