13

I am working on a ASP.Net WebForms legacy App and i need to retrofit one new feature into it. I am using a generated DataSet (Using VS 2013) to bridge the gap between ReportViewer and SQL server (Local reports, rdlc).

Everything Works nicely except one thing: Float conversions. On two Windows 8.1 En_US systems -10.5 (One of the values in a column) is seen on the report as -10.5 but on the server (Win 7 SP1 Es_CO) it displays as -105 even though the query is returning -10.5 on the server's local SQL instance.

I've checked out the generated code for the dataset and it casts an object from the datarows straight into double so i am assuming SQL server already handles the conversión (Via a CAST instruction on each column)

Is there anything i can do about it? It is worth mentioning all requests to the server (Win7 machine) came from one Win8.1 En_US machine.

Status update: I am hinted (Not completely sure) that the fault is in the conversion from SQL to CLR types, as marking the report column as String yields the same result.

Improve this question
10
  • 1
    What value does the debugger tell you when you hit a breakpoint?
    – Charlie Brown
    Commented Feb 7, 2014 at 20:23
  • 1
    Have not yet been able to trigger breakpoints nor Trace/Debug calls on the generated source. It's been nigh impossible to diagnose this issue
    – Machinarius
    Commented Feb 7, 2014 at 20:34
  • 3
    It sounds like your .net application runs a different Globalization culture than the SQL Server does. Try setting the culture specifically in the thread for your website: msdn.microsoft.com/en-us/library/… You can also provide NumberFormatInfo to the casts if you'd prefer
    – Allan S. Hansen
    Commented Jul 23, 2014 at 19:06
  • 1
    @Allan- I do not agree on this solution and have personal experience of this. Setting culture whatever required introduces more bugs and confusion and need full attention when switching cultures.Consider this is happening for 500+ pages. Solution is to treat with invariant culture and format for display.
    – Amit
    Commented Jan 22, 2015 at 7:25
  • @Amit Globalization is for formatting. It doesn't change datatypes. When displaying datatypes, you re talking formatting and then you're talking Globalization.
    – Allan S. Hansen
    Commented Jan 23, 2015 at 8:33

2 Answers 2

Reset to default
1

I would want to know what the Type of the column in the DataSet was, and track that through until it arrives at the report. Is the web server on the same machine as the database, or is it on a different server? Maybe you use WCF to transfer that DataSet between the two. Also check the locale of the Report in the designer (look at Properties), and the data type that is being used for that field in the report (I just poke around in the XML of the RDLC file).

We had a similar issue where values with decimal places (like "10.5" became "105" when the value was serialized and deserialized without paying enough attention to the locale. For example, if you parse "10.5" in German, it will interpret the "." as a thousand separator, and ignore it, giving you the result "105". I'm guessing it's the same in es-CO.

Improve this answer
0

This situation comes in cross laguage scenario where your UI thread culture is different from processing thread or server thread. Use consistent Cultureinfo.InvariantCulture while passing data from UI to server to SQL and format only when displaying on UI.

One more recommendation is to use decimal at SQL end.

Hope this helps.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.