I'm using SSRS to build a report that can be exported to multiple types (PDF, XLS, CSV...)
The report consists in a table and some columns have numeric values such as latitudes or longitudes, something like -1,234567
When exported to csv and opened in excel, these numeric values loose the ','
Is it possible to make this values as text in report builder so it's kept as it is, with no formating changes on the csv file?
tks
An easy way to do this is to use a Format expression instead of accessing your report field directly.
e.g.
=Format(Fields!OrderPrice.Value, "#,###.00")
instead of..
=Fields!OrderPrice.Value
This will coerce the numeric value into a string. The number format will ensure you keep the comma. When exported via CSV, the value will be wrapped in quotes, meaning your formatting comma won't trip a parser up.
Massive caveat
This solution is not perfect. The problem is that although you get the desired result in your CSV file, any SSRS Excel export you produce will flag that field as textual content, meaning that your users will have to tell Excel different every time they open that report.
Similarly, if someone opens your CSV file in Excel, the same thing will happen. Excel isn't smart enough to recognise that the thing in quotes is actually a number, and it'll again, treat the column as textual.
The reality is that CSV is a limited format. It's primary concern is content - it doesn't convey formatting information, and even if it were possible to give SSRS more "guidance" on individual export routines, the inherent limitations of the CSV file format mean that some sort of compromise ( or extra work on the Excel end ) has to be made.
Related
In an SSRS 2008 R2 report, the users are going to export the data to: csv (comma delimited) and excel.
I am using the following to display if a column is visible or not:
=IIF(Mid(Globals!RenderFormat.Name,1,5)="EXCEL" AND First(Len(Fields!CustomerNumber.Value)) > 0,False,true)
I have set the DataElementOutput=Output for the textbox that displays the value.
I have left DataElementOutput=Auto for the textbox that contains the column header.
When exporting to csv (comma delimited) or excel, I basically want the column to be visible when there is data in the field and the column not to be visible when there is no data.
The code works for excel but the code does not work for comma delimited.
Thus, can you tell me what I can do so the column is not disaplyed when the data is exported to csv (comma delimited)?
You may attempt to do this with a continuation of statement accounting for the "CSV" output type.
=IIF( (Mid(Globals!RenderFormat.Name,1,5)="EXCEL" OR Mid(Globals!RenderFormat.Name,1,5)="CSV") AND First(Len(Fields!CustomerNumber.Value)) > 0,False,true)
Or a switch statement:
=Switch(Mid(Globals!RenderFormat.Name,1,5)="EXCEL" AND First(Len(Fields!CustomerNumber.Value)) > 0,False, Mid(Globals!RenderFormat.Name,1,5)="CSV" AND First(Len(Fields!CustomerNumber.Value)) > 0,False,true)
However....
The problem may be due to the nature of a csv file being a simpler format that cannot handle this in output. It depends on how SSRS handles the output if it is hard writing the output before the write operation. It may simply not work because of the limitations of the format of CSV. If this was the case you may be able to simple take the Excel output and save it to CSV either in code or a manual operation.
My 2008R2 SSRS report contains a detail column called debit which is formatted like "#,0.00". When I export the file via .csv the debit column does not always have the right formatting of 0.00. If the number is 0, then what appears is "0". If the number is 123.40, then it appears as 123.4. If the number is 123.44, then it appears as 1213.44.
I want each number in this column to always have 2 decimal places in the .csv file. I checked out many other articles on stackoverflow about this, but none seem to address this issue correctly.
I tried changing the format to many other formats. I noticed when I changed the format in SSRS to "C" for currency, then the 2 decimal places appeared. But the problem with that is my users do not want the "$" symbol.
I tried changing the CSV export to ASCII format in the config file, but that did not work.
I used the code here:Non-Unicode CSV Export from SQL Server Report Server
Can anyone help me with getting the format correct in the CSV file without mannually changing the CSV file?
Thank you!
The problem mentioned is report header's are being displayed when user generate report for CSV format, which is not supposed to be like that. But actually in CSV Format, While in the preview , we can hide or show report header's and it doesn't show textbox names .
While in the exported/generated one , the CSV format hides the report's headers, but instead of that it shows textbox names and any changes We made in the properties to change that textbox name to make it as blank or disappear, it reflects on that column values but doesn't on that textbox name.
So I want to mention that better We can give some other meaningful names or by default it shows as 'Textbox1', but we must give any valid name to that textbox name and it appears on the generated CSV format.
NOTE: I also want to mention that all visibility properties works well with the report header's but not on the textbox names.
I am using Office 2003
On Access, I export values from a form into a .xls, after that using mail merge on word I import the data to be displayed on the file. Data such as dates and strings are displayed correctly.
In Access theres the value 9,916.12 wich is exported to the .xls as 'price' that contains 9,916.12, both values match keeping the same format, but when mail merge kicks in the value displayed on the document becomes 9916,1200000000008.
I am lost as to what is causing that. The field that is being exported contains only 2 decimals, it displays on excel as a value with only 2 decimals yet when word reads it, it adds random decimals to it. If I manually alter the value on excel the error persists, so does it if I choose a different record to be exported.
Any tips on how to solve the problem?
See this Microsoft Answers discussion and this in-depth description on how to use a merge field such as {Mergefield NumberFieldName \# ",0.00"} to work around the issue. It's been awhile since I had to do mail merges, especially with Word 2003, but I think that should do it.
I am using an expression to display currency depending on if the value is in the millions or in the thousands. This expression is set in the Format property of my report:
=iif((Fields!PrevActual.Value < 100000), "'$'#,,0,'K';('$'#,0,'K')", "'$'0,,.0,'M';('$'0,,.0,'M')'")
In this way, if the value is 1,500,000 the number will display as $1.5M and if it's 15,000 it will display as $15k.
The problem is when I export the file to Excel. The numbers in the thousands retain the formatting, but the numbers in the millions lose it. So I have a spreadsheet with numbers like 1,500,000 and $15k. All numbers are exporting as text.
Does anyone know of a way to keep the formatting in excel so it matches how it's displayed on the SSRS report while making sure it's also still a number?
Essentially, I want to mimic what excel was doing before we automated this report with SSRS. Numbers in the millions were in this custom number format: $#.0,,\M and thousands were in this one: $#,K.
Thanks!
If you export the excel formula then it can work. i.e. export
="text(1500000," ""'$'0,,.0,'M';('$'0,,.0,'M')"")"
Excel will then convert the formula to the final formatted value
$15M
The tricky part is making the format string valid in excel, and creating an SSRS formula which will concatenate strings and generate an Excel formula.
This can help:
http://msdn.microsoft.com/en-us/library/ms159220%28SQL.90%29.aspx
Suppose I have a field with a date value in a Reporting Services template, e.g. =CDate("2010.12.03"), I apply the "d" format to this cell, which, according to the description, "will reflect the regional settings of the report". I generate the report using the English language, the date is displayed as 12/03/2010, which is fine. Now when I export this report to excel, I have no idea what the __ happens.
First scenario: the regional settings of the computer are set to English (United States). When I open the excel document, the value seen in the cell is 12/03/2010, as expected. When I click on it, I can see that the actual value stored in the cell is 2010.12.03, which also seems reasonable - some formatting is applied to the cell, it's not simply exported as text. But when I try to figure out what type of formatting is applied, by right clicking and checking Format Cells, I see that the format is "General", i.e. none! How can this be ? This is Excel 2010 by the way, but the file itself is .xls, of course.
Second scenario, where it gets more interesting: now the region of the computer is set to e.g. Lithuania, where the date format is 2010.12.03. I open the same document and see 12.03.2010. Now that simply does not make any sense. Exporting many times I've encountered that sometimes the cell is formatted as [$-10409]m.d.yyyy in excel (under the Custom section). What is this, what does the 10409 mean ? The weirdest part of all: if I close the document without saving, change the computer region back to English (United States), reopen the document, the format is now [$-10409]m/d/yyyy ! HOW is this possible !??
Basically the same thing happens with numbers and with thousand/decimal separators - excel uses the region of the computer to format these, but the actual format of the cell can be something like [$-10409]#,##0.00;-#,##0.00 or General - again, depending on the region of the computer, direction of wind and the temperature outside.
My question is then, first of all, what the __ is going on ? Second, how should the excel document behave according to the specs, i.e. what does the statement that a format "will reflect the regional settings of the report" in the BIDS designed, where I chose the "d" format for the date textbox, mean ? Does it mean, that the format will be determined by the language of the report and the result will look the same on all computers in the world (which makes sense, since this is how other formats behave, i.e. if you export the date to a pdf, it stays the same always) ? If not, which appears to be partially the case in excel, why doesn't the exported date cell have the regional date format, i.e. the one that you normally use in excel, the one which formats the date according to the region of the computer ?
Are these some kind of limitations of excel or what ? Why can't we have consistent behavior, i.e. either make everything sensitive to the culture of the computer viewing the document or don't, why is the actual behavior somewhere in between ?
Excel uses a custom encoding for the date, and uses the machine regional settings as a hint on how to format the contents. The encoding is archaic, and has lots of specific, historic gotchas.
This means that the kinds of bugs that you see often do happen - you'll have data that's been exported to Excel, which then has its formatting and contents mangled once opened for the first time by the actual Excel application. The problem can be anywhere along the line - maybe the library that exports the data to Excel doesn't deal with some of the more esoteric historic cases well, or maybe Excel is confusing itself along the way.
I've had some success in the past with exporting dates as a strings to a CSV file, stripped of formatting, and then importing them into Excel/opening them with Excel.
I sorted my date formatting problem by:
adding calculated fields for the dates :
=IIF(IsNothing(Fields!Date_Delivery_Confirmed.Value),nothing,DateSerial(DatePart("yyyy",Fields!Date_Delivery_Confirmed.Value), DatePart("m",Fields!Date_Delivery_Confirmed.Value),DatePart("d",Fields!Date_Delivery_Confirmed.Value)))
set cell Textbox as dateformat
how I am using *dateformats (localised) I checked my server laptop and report are set to the right language
I have aligned elements vertically in the report so it ( the visual gaps) doesn't create extra empty columns when exporting to excel. Because 2 excel columns merged to 1 date-cell will never get any format but "General format"