实际文化是否与 SQL 到 CLR 浮点-双精度转换相关？

Question

我正在处理一个ASP.Net WebForms遗留应用程序，并需要将一个新特性集成进去。我使用生成的DataSet（使用VS 2013）来连接ReportViewer和SQL Server（本地报表，rdlc）。

一切工作都很好，除了一个问题：浮点数转换。在两个Windows 8.1 En_US系统上，报告中一个列值为-10.5的数据在报告中显示为-10.5，但在服务器上（Win 7 SP1 Es_CO），它显示为-105，尽管查询确实在服务器的本地SQL实例中返回了-10.5。

我已经检查了DataSet的生成代码，它将datarows中的对象直接转换为双精度浮点数，因此我认为SQL Server已经通过每列的CAST指令处理了这种转换。

有什么办法可以解决吗？值得一提的是，所有对服务器（Win7机器）的请求都来自于一个Win8.1 En_US机器。

状态更新： 我暗示（不完全确定）故障在于从SQL到CLR类型的转换，因为将报表列标记为字符串会产生相同的结果。

- Machinarius

---

当您遇到断点时，调试器告诉您什么值？ - Charlie Brown

尚未能够在生成的源代码上触发断点或跟踪/调试调用。诊断此问题几乎是不可能的。 - Machinarius

看起来你的.NET应用程序运行的全球化文化与SQL Server不同。尝试在你网站的线程中特别设置文化：http://msdn.microsoft.com/en-us/library/system.threading.thread.currentculture%28v=vs.110%29.aspx 如果你愿意，你还可以为类型转换提供NumberFormatInfo。 - Allan S. Hansen

@Allan- 我不同意这个解决方案，并且有亲身经历。设置所需的文化会引入更多的错误和混乱，并且在切换文化时需要全神贯注。考虑到这将发生在500多个页面上，解决方案是使用不变的文化并进行格式化以供显示。 - Amit

@Amit 全球化是用于格式化的。它不会改变数据类型。当显示数据类型时，你在谈论格式化，然后你在谈论全球化。 - Allan S. Hansen

Answer 1

我想知道DataSet中列的类型是什么，并跟踪它直到报告。Web服务器是否与数据库在同一台机器上，还是在不同的服务器上？也许您使用WCF在两者之间传输该DataSet。还要检查设计器中报告的区域设置（查看属性）以及报告中用于该字段的数据类型（我只是在RDLC文件的XML中四处查看）。我们遇到了类似的问题，其中具有小数位的值（例如“10.5”）在序列化和反序列化值时，如果没有足够注意区域设置，就会变成“105”。例如，如果您在德国解析“10.5”，它将把“.”解释为千位分隔符并忽略它，从而给出结果“105”。我猜在es-CO中也是如此。

- Richardissimo

Answer 2

这种情况通常出现在跨语言场景中，其中您的UI线程文化与处理线程或服务器线程不同。在从UI传递数据到服务器和SQL时，请使用一致的Cultureinfo.InvariantCulture，并仅在显示在UI上时进行格式化。

另一个建议是在SQL端使用十进制。

希望这可以帮助您。

- Amit