CSVRenderer - Date style is not enforced on render\export

@boaz.goldstein

The setting of rsreportserver.config has more priority than the setting of Aspose.Cells.ReportingServices.xml.

So the FieldDelimiter of rsreportserver.config will cover the FieldDelimiter value of Aspose.Cells.ReportingServices.xml when you will set the FieldDelimiter of rsreportserver.config.

Thanks Shakeel,
Can you check what value should i use to specify a “tab” as field delimiter ?
Using current settings in rsreportserver.config - when i select to export the report (in SSRS) to ACTXT i dont get the desired result (tab delimited TXT file).

Thanks
BoazG, Sizmek

@boaz.goldstein

We were able to observe the issue and logged it in our database for investigation and for a fix. Once, the issue is resolved or we have some other news for you, we will update you asap.

This issue has been logged as

  • CELLSRS-514 - ACTXT does not get the desired result for tab delimited TXT file

Thanks for the update!
i will wait for additional update from you regarding the fix.
thanks
BoazG, Sizmek

@boaz.goldstein

Please download and try the following fix and let us know your feedback.

Hi Aspose Support, Shakeel

Aspose.Cell for SSRS v17.8.0.2 was tested and found to be fixing the problem of tab-delimited file.
I have deployed it to our production server.

Thanks alotfor your prompt assistence.

BoazG, Sizmek

@boaz.goldstein

Thanks for your feedback and using Aspose APIs.

It is good to know that your issue is resolved. In case, you face any issue, please feel free to let us know. We will be glad to help you further.

Hello Again Support,
I would like to report additional issue we encounter since we upgraded to the new Aspose.Cell SSRS version.
Customers are now compaining that rate fields (with %) - when exported to csv\txt - includes an additional space between the value and the “%” sign. a value looks like: “0.58 %”.
Can we have the space removed?
This is extremly critical as one of our biggest customers is complaining.

Thanks
BoazG, Sizmek R&D

@boaz.goldstein

Thanks for considering Aspose APIs.

Please provide us all the relevant files like RDL, exported CSV/TXT and XLS file for comparison. We will look into your issue and help you asap.

Hi Sakeel,
Thanks for the prompt response.
See attached example for a CSV which was created with Aspose.Cells latest version in our prod servers.
Please note that in the RDL setup, we use the culture value (a parameter that comes as inpt for the report generation) on all the fields in a single row.
Thanks
BoazG, Sizmek R&DSizmek - AsposeCells SSRS - Culture Examples.zip (19.8 KB)

@boaz.goldstein

Thanks for providing the needed files. We were able to observe the issue in your CSV files as per your description and logged it in our database for investigation and for a fix. Once, the issue is resolved or we have some other news for you, we will update you asap.

This issue has been logged as

  • CELLSRS-515 - When exported to CSV or TXT - it includes an additional Space between the Value and the Percentage sign

@boaz.goldstein

Please provide report definition description about rate field. We will generate test report definition file by ourselves for investigation and fixing this issue.

Hi Shakeel,
In the report definition, when we have a rate field value used in a cell, we use the fomat “P” for the format of the same cell (format property of the cell). so if the value in the data is “0.03433” than the output should look like “3%”.
As i mentioned previously, we also put the “Culture” value in the Language property of the cell. The Culture parameter is a report input and we populate it at report runtime by the UI user who runs the report but nevertheless, i do not understand why it affects the value in the output csv when it comes to a rate type field.

In addition, I have another open SR for improper CSV structure.
please check the screen shot.

I see for example line numbers on places that should not start a usual seen CSV line record. I can also identify columns that have a “coma” in their values and these should normally be warped in quotes for the column value to parse right.

Needless to - we are working with Aspose.Cell SSRS V1.9 for over 6 years now and for very long time we did not get these type of issues. Can we trust that the new version to support all the capabilities and fixes from previous versions?

Since we have complaining customers awaiting on a fix here, can you please also share an ETA - the time it will take you to provide a fixed version of the product ?

Thanks
BoazG, Sizmek

@boaz.goldstein

Thanks for considering Aspose APIs.

We have logged your comment in our database for product team consideration and investigation. Once, we will have some fix or any other update for you, we will let you know asap.

@boaz.goldstein

We have found the issues and fixed them.

Please try the fixed version i.e. Aspose.Cells for Reporting Services 2012 V17.8.2.

Copy Aspose.Cells.ReportingServices.DLL into ${Report Server}/bin/ folder and export report file again.

If you still face the issues, please inform us. We will check it ASAP.

hi Sahkeel,
thanks for the update.
I encounter ERROR strings in result CSV file when using en-ES culture in the report
see attached 3 examples for CSV files using the Aspose: 2 using the new version you provided, 1 using the previous version 17.8.0.2
Aspose Tests 17.7.2.0.zip (28.6 KB)

Your quick response is very much appreciated.

thanks BoazG, Sizmek

@boaz.goldstein

We were able to observe the problem relating to en-ES culture and logged your comment in our database. We will evaluate it and fix the issue. Once, there is some news for you, we will update you asap.

thank you Shakeel !

@boaz.goldstein

Please try the fixed version

If you still face the issues, please post report definition description of error field here. We will check it ASAP.

hi Shakeel,
thanks.
i have tested version 17.8.3 you have sent and still the #Error message in date fields persists - when a report is running with culture = “en-ES”. when the same report runs with the default culture “en-US” date fields looks alright!.
Apart to the #Error message, all other formatting and output looks good! yet - this is not enough. we need to be able to support all cultures.
by the way - when testing with en-AU (Australia) the results are good!
the same goes for hebrew (he-il).

Please try and provide immediate assistence.

attaching all result tests
17.8.3.zip (38.2 KB)

thanks
BoazG, Sizmek.