David, is this issue posted on Connect?  If they aren't aware of it, they can't fix it.  Don't get me wrong, I'm not saying it's okay that this problem existed in the first place; I know that they took many shortcuts to deliver the product on time.  But unless you bring these issues front and center, they won't really know they exist.  Thanks for pointing it out here, but if you want them to fix the issue, you really should file an issue on Connect.  And if you want community support, post the link here so we can all weigh in with our votes.

What do you mean, "can not"? Do you have a passport?  If so, click "Sign In" in the top right corner of the interface.  Kind of an annoying requirement, but I guess they want you to feel some accountability for what you post.  :-)

I looked at 233903 and this looks specific to reporting services (and not being overly familiar with RS, the workaround suggested by MS does not make much sense to me).

I think this issue may be related, but I think it will get more visibility as a separate issue not chunked under reporting services.

I actually think the voting helps give them guidance as to which bugs affect the most people, and how badly.  With a product this complex and with this many potential bugs/enhancements filed, they have to prioritize somehow.  If they fixed everything and could not rank the things they should fix in chunks, we would never see a service pack, never mind a new release.

I didn't vote for it, because it has been closed.  And because it didn't affect me.

As far as pride in what you do, there is a big difference between you or I writing a stored procedure, and a mammoth product like SQL Server.  They have to cut their losses at some point, or else they will never ship.  I'm going to go out on a limb here and guess that more people would be angry if they delayed shipping by a month to make you happy, than the current state of affairs.

If you think this is the biggest problem in SSMS, that's fine.  The problem is that I know there are still many others that I, personally, deem more important.  I'd have to imagine that the team's priority list is different from yours, also, or this issue would have been fixed.

Your issue has a workaround... pick your language of choice, and don't use SSMS directly to export data.  Data extracts should not be dependent upon pointing and clicking in a GUI anyhow, IMHO.

David:

Yes, I perform data extracts to CSV all the time.  Like Jeremy, I have written a few different EXEs to handle this.  Obviously, this is something that could be fixed.  But just because something is embarrassing and obvious does not automatically make it to the top of the pile.  If you want Microsoft to push this omission to the top of their priority stack, you're going to have to convince them, not me.  I am virtually powerless to do anything about this.  I have my extract tools in place, and I don't use SSMS to save CSV output, so I wouldn't even know what to ask for.

You've highlighted a few bigger problems in SSMS, in my opinion.  For scripting stored procedures, for example, I use tools from other vendors such as Red-Gate.  And there are so many issues with the visual designers that I warn others to stay away from them completely.

SSMS is decent at some things, and horrible at others.  But you seem to be contradicting yourself... you are saying that this CSV extract problem should be their #1 priority and needs to be fixed, yet you're complaining about how crippling just using SSMS is?

I am not patting anyone on the back.  Take a look at my bug reports and suggestions on Connect; and keep in mind these do not include any that I made when we were still submitting issues at beta.microsoft.com and/or ladybug.  I have been very vocal in my complaints about SSMS.  One of the nice things in SP2 that I believe was originally initiated by me was the change to the context menu when right-clicking a view.  It used to just have "Modify" and I would swear about 40 times every time I chose that and got the brain-dead visual editor.  Now it has "Edit" which brings up the code (thank you!) and "Design" which brings up the dumb drag and drop point and click nonsense.

As far as SP2 goes, I think they delivered a lot, but they obviously can't please everyone.  Not *all* of the problems were in SSMS, and to be honest, I'd rather they kept fixes to the engine and fixes to an optional client tool separate anyway.  I don't use maintenance plans except at one consulting site, but for some people the changes here have been great (especially the elimination of the dependency on SSIS).  I am using several custom reports in SSMS that would otherwise have to be developed as a .NET application and hosted on a web server somewhere.  I have one system where there are 500 databases with identical schema, so the simple addition of a DB_ID() parameter to OBJECT_NAME(), and the new function OBJECT_SCHEMA_NAME(), have helped in several of my admin tasks.

So yes, they have fixed some of the things we have complained about.  But like I said, you need to convince /them/ that this should be a priority.

I updated the client tools on my workstation here at the office to SP2, and reviewed the issue you pointed to earlier, 132806, to which you said you couldn't see a resolution in SP2.

In Management Studio I found the following option:

Tools | Options | Query Results | SQL Server | Results to Grid |

Quote strings containing list separators when saving .csv results

After enabling this checkbox and opening a new tab, I ran this query:

SELECT

   'foo','bar','foo,"bar'

UNION

SELECT

   'bar','foo','blat'

And the output CSV file (File | Save Results As | Export Files (*.csv)) looked like this:

foo,bar,"foo,""bar"

bar,foo,blat

(It handles doubling up of double quotes within a quoted string, also, which I thought for sure would cause trouble).

I also tested the original query that you posted in your first comment above, and the output CSV file looks correct in Notepad:

"this should return two column, not three, four or one.",column two

However, when I double-clicked it to open it in Excel 2007, it all showed as one column.  This is because the default output format for files in Management Studio is Unicode.  To avoid this problem, you need to click the little arrow on the Save button, choose "Save with encoding", switch from Unicode to ANSI, and then the new file will open correctly in Excel.  (You can also change it from Unicode to ANSI within Notepad or other text editors.)  There may be an easier path using File | Open manually from within Excel, but I didn't investigate that.  Note though, that if you output really does have Unicode data, this is not necessarily a desirable output either.

I will be filing a suggestion on Connect to provide an option for default encoding when saving files.  We don't all have Unicode data and we don't always want to jump through these extra steps just to produce a file we can open in Excel.

Hope this information helps.

No problem David.

BTW, I updated the original issue with a comment and a request to re-visit.  I also opened two more issues as a result of my investigation.  I encourage you to consider Connect an ally and not a waste of time.

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=132806

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=259779

https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=259781