是实际的文化相关的SQL CLR浮动双重转换？ [英] Is the Actual culture related SQL to CLR float-double conversions?

问题描述

我工作的一个ASP.Net WebForms的遗留应用程序，我需要改造的一个新特点进去。我使用的是生成的数据集（使用VS 2013）弥合的ReportViewer和SQL服务器（当地媒体报导，RDLC）之间的差距。

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).

一切都很好，除了一件事作品。在两个Windows 8.1 EN_US系统-10.5（一列中的值）上看到的报告为-10.5，但服务器（Win 7的SP1 ES_CO），其显示为-105即使查询的是在服务器上的本地SQL实例返回-10.5。

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.

我已经签出了产生code的数据集并将它转换从数据行的对象直接进入双所以我假设SQL服务器已经处理转换（通过在每一列CAST指令）

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)

有什么我可以做些什么？值得一提的所有请求给服务器（Win7的机器）来从一个Win8.1 EN_US机

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.

状态更新： 我暗示（不完全肯定），该故障是在从SQL到CLR类型的转换，标志着该报告列字符串产生同样的结果。

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.

推荐答案

我想知道在DataSet中列的类型是，并跟踪通过，直到它到达的报告。是在同一台机器上的Web服务器的数据库，或者是在不同的服务器上？也许你使用WCF传输，两者之间的数据集。同时检查报告的语言环境中的设计师（看属性），以及正在报告中使用该字段的数据类型（我只是闲逛在RDLC文件的XML）。

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).

我们曾在那里值与小数位（如10.5变成了105时，值序列化和反序列化没有给予足够的重视的语言环境。例如，如果你在德国解析10.5类似的问题，它PT的。作为一个千位分隔符将跨$ P $，而忽略了它，给你的结果105。我猜它在ES-CO一样的。

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.

这篇关于是实际的文化相关的SQL CLR浮动双重转换？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！