這裏有兩個問題。
第一個是舍入。這可以方便地與Round
功能SQL來完成:
SELECT Round(8660.125, 2);
-- returns 8660.130
第二,正如你所看到的,就是小數點後3位,這仍然返回。這是由於數據類型。你有你的四捨五入值,但它仍然顯示一個額外的數字。
可以解決這個問題是這樣的:
SELECT Convert(decimal(16, 2), 8660.125);
--returns 8660.13 by implicitly rounding--you could round first but not needed
然而,這兩個值以上是相同數字。在我看來,你不應該在SQL Server端處理演示。如果您想要兩位小數,請將您的SSRS報告中的單元格格式設置爲#.00
。這將確保您獲得所需的(舍入)小數位數,無論如何!沒有必要的功能。只是一個簡單的屬性。
這與日期的原理相同。日期的基礎值僅爲,數字爲。但有很多方法可以向用戶提供日期 - 具有長名稱或不同的部件順序或使用不同的分隔符。每當你改變日期格式時,你會一直回到你的SQL並改變你的Convert()
風格?
您不希望SQL Server在報告中確定這些數字的字體,顏色,大小,填充,樣式,位置或可見性。這些都必須在設計時手動設置。那爲什麼會顯示這個值(當這些值完全相等時)會有什麼不同?在我看來,將其推入SQL查詢將把關注的領域轉移到錯誤的地方。這就增加了不需要在那裏的查詢的複雜性(而不是「智能」)!我沒有看到將單元格的數字格式設置爲「添加智能」。
這是一個介紹性問題,因此請將它保存在適當的位置,以便解決所有其他演示文稿元素 - SSRS報告。
更新
我能想到的一個場景,你會想在您的查詢進行轉換,那就是當值將在更多的計算可以進一步使用和有關業務規則所述計算需要它。例如,如果你計算銀行利息,他們可能會有規則,比如「在第一輪結束後保留4位小數,然後在第三步後最後到達小數點後兩位(美元和美分)。」但這是一個不同的故事:現在的值很重要,不僅僅是它的顯示。
如果您發佈了一個示例查詢或您的查詢的摘錄,它可能會有所幫助。 –
@Aaron ...會做 – MikeTWebb
通常在報告中,四捨五入是在顯示屏上完成的,而不是改變底層數據。如果您不需要,請不要執行數據轉換。 – DOK