Different combinations of these settings can bring results in the output that are incorrect or partial data. This is because Microsoft didn't think it was important enough to fix these issues. I'm only explaining what happens with CSV files when sending the results to a file.
To get good results, do the following:
Open new query window (new tab/session) ... if you do not, configuration below is lost and set back to the defaults
Write the query to handle the quote inside the quote, and also wrap all string data types in quotes. Also be aware that different DBMS and programming language grammars accept a different syntax for an escaped double quote (if using this output as input to another system). Some use \"
. Some use ""
. XML uses "
;. Probably a reason Microsoft chose to ignore this functionality, so they didn't have to deal with the arguments.
.. If Escape Sequence of new system is ""
.
SELECT '"' + REPLACE(CAST(column1 AS VARCHAR(MAX)), '"', '""') + '"' FROM table1
.. If Escape Sequence of new system is \"
.
SELECT '"' + REPLACE(CAST(column1 AS VARCHAR(MAX)), '"', '\"') + '"' FROM table1
Configuration:
Query Options > Results > "Include column headers when copying or saving the results" checked
Query Options > Results > "Quote strings containing list separators when saving .csv results" - BROKEN; DO NOT USE!
Query Options > Results > others unchecked
Query Options > Results > Text > comma delimited (setting on top right corner)
Query Options > Results > Text > "Include column headers in the result set" checked
Query Options > Results > Text > others unchecked
Query Options > Results > Text > "Maximum number of characters displayed in each column" - set to max length so strings don't get truncated.
Query > Results To File (this is a toggle between all 3 options)
Execute query (F5)
Prompt for file name of report
Open file to look at results
NOTE: If you need to do this on a regular basis, you're better off
just developing a program that will do this for you in .NET or Java,
or whatever language you are comfortable with. Otherwise you have a
high probability of making a mistake. Then be extremely aware of the
syntax of the system you're importing into, before you define your
export out of SQL Server.