I'm using a .XLS template instead of .RTF.
The problem is, even when I format the excel field cell to Text, I'm still getting #NUM! in the output.
The template is considering the data as an exponential value because of the character "E" in between the numbers. The exact value to be displayed in output is "12E18157" but I get #NUM! no matter what I do.
Any suggestions?
I was not successful in trying to format the .xls template cell because no matter how we format the cell, the template is considering the value as exponential value so I have concatenated a space for that particular column in my query(XML Data Definition file) itself and it fixed the problem.
Related
long time viewer, first time poster.
The issue I am struggling with relates to how my timestamp data appears in excel once I've run my code in snowflake and exported it to CSV. Unfortunately at the moment I am required to double click on these timestamp cells, once in exported into excel, for the true format (how it appears in results in snowflake) to appear.
There is a manual workaround to amend once the data is in excel, however I am automating this report for a client and therefore it must be presented correctly for them prior to the export.
As it stands (see below) the timestamp begins with YYYY-MM-DD and I have been asked to flip this firstly, to begin with DD. I thought that given I need to reformat the current timestamp, I may as well set it up correctly so the timestamp perhaps comes out as text, within the csv export? (from what I have read in other forums if you convert to text it is displayed in excel exactly how it appears in snowflake).
image.png
As you can see, I continue to get the "Cant Parse" error. The example timestamp given, is row 1 of the 'QuoteDate' variable.
The second part of the issue (or really the primary part of the issue) is how the timestamp completely changes format when exported (CSV) to excel. In the screen shot below I have double clicked the first 3 rows, leaving row 4 selected in order to show you all the error - which is the formula bar displays the correct format but the cell itself does not.
image.png
I hope this all makes sense and would love any assistance on how to amend this timestamp issue to run the code correctly, and present my client with a properly formatted timestamp within their extract.
Thank you :)enter image description here
For changing format
SELECT to_char ( to_timestamp ('2019-01-02 09:36:22.507' , 'YYYY-MM-DD HH24:MI:SS.FF') , 'DD-MM-YYYY HH24:MI:SS.FF') AS TS
Timestamp/dates are stored as NUMBER in database, you need to convert in required format for correct display.
to_timestamp --> Converts an input expression into the corresponding timestamp. This expects the input to be in the format provided as second argument.
to_char --> Converts the input expression to a string format.
For preserving data format while converting from csv to excel check Saving to CSV in Excel loses regional date format
I have imported a csv file from MySQL, documenting part numbers and descriptions. Some of these part numbers have values like 1234567890987654321, which is then shortened by excel to 1.23e18. Problem is, I cannot query a part with this formatted data.
Now I cannot feasibly go through every cell as there are just over 28000 of them. I have converted the row to text however this does not change the data in the cell.
The closest thing I have to a solution is deleting the cells and then undo-ing, which gets the number in a textual format but then gives me a 'number in text field' error.
Also some parts have part numbers like 12E345 which is then changed to 1200000000000000000000000000000000000000000000- you get the picture.
Very annoying...
I would like a batch process to change all the values to text format, thanks in advance.
Instead of just opening the CSV in Excel, import it with Data -> External Sources -> From Text.
You will have to first pick basic things like "delimited" format, whether first row contains headers, separator etc.
In the third part of the "Text Import wizard", you can pick data type of each column - picking Text for your columns will probably solve the problem.
When importing a string value from a CSV file or inputting it from through UI Services that has a format similar to a date format (example: cost center number of 2010-10), it is automatically converted to a date format (2010-10 is converted to 10/1/2010). How can you tell Google to keep the value in string format?
Adding a single quote ' before a value will tell google to treat the text as-is, rather than convert it to a date or a number. For example, entering '2010-10 will show up as 2010-10 (i.e. the quote is not displayed) and will not be converted to a date.
I'm not sure how importing from a CSV file works, but you could massage the data there to avoid this problem. The quote character obviously works for entering anything directly from the console.
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'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.