Является ли фактическая культура связанными SQL с CLR плавающими двойными преобразованиями?

Я работаю над устаревшим приложением ASP.Net WebForms, и мне нужно модифицировать в него одну новую функцию. Я использую сгенерированный DataSet (использование VS 2013), чтобы устранить разрыв между ReportViewer и SQL-сервером (локальные отчеты, rdlc).

Все работает хорошо, кроме одного: плавающие преобразования. В двух системах Windows 8.1 En_US -10.5 (одно из значений в столбце) в отчете указано как -10.5, но на сервере (Win 7 SP1 Es_CO) оно отображается как -105, хотя запрос возвращается -10.5 на локальный экземпляр SQL сервера.

Я проверил сгенерированный код для набора данных, и он отбрасывает объект из datarows прямо в double, поэтому я предполагаю, что SQL-сервер уже обрабатывает конверсию (через инструкцию CAST для каждого столбца)

Есть ли что-нибудь, что я могу сделать? Стоит отметить, что все запросы на сервер (машина Win7) поступали с одного компьютера Win8.1 En_US.

Обновление статуса: Я намекнул (не совсем уверен), что ошибка заключается в преобразовании из SQL в типы CLR, поскольку маркировка столбца отчета, поскольку String дает тот же результат.

Ответ 1

Я хотел бы знать, что такое тип столбца в DataSet, и отслеживать его до тех пор, пока он не попадет в отчет. Является ли веб-сервер на том же компьютере, что и база данных, или он находится на другом сервере? Возможно, вы используете WCF для передачи этого DataSet между ними. Также проверьте локаль отчета в дизайнере (посмотрите на свойства) и тип данных, который используется для этого поля в отчете (я просто ткнул в XML файла RDLC).

У нас была аналогичная проблема, когда значения с десятичными знаками (например, "10.5" стали "105", когда значение было сериализовано и десериализовано, не уделяя достаточного внимания языку. Например, если вы разбираете "10.5" на немецком языке, интерпретирует "." как тысячу разделителей и игнорирует его, давая вам результат "105". Я предполагаю, что это так же в es-CO.

Ответ 2

Эта ситуация возникает в сценарии перекрестного лагунга, где ваша культура потоков пользовательского интерфейса отличается от потока обработки или потока сервера. Используйте согласованный Cultureinfo.InvariantCulture, передавая данные с пользовательского интерфейса на сервер в SQL и форматируя только при отображении в пользовательском интерфейсе.

Еще одна рекомендация состоит в том, чтобы использовать decimal в конце SQL.

Надеюсь, что это поможет.