LINQ to SQL - 十進制數據類型被截斷，而不是舍入

我有一個十進制數據庫列（6,1）當用LINQ to SQL保存記錄時，它會截斷值而不是四捨五入。因此，例如，如果在生成的LINQ to SQL查詢中傳遞給此列的參數具有此值... - @ p1：輸入Decimal（Size = 0; Prec = 6; Scale = 1）[01213] 222.259] 數據將在數據庫中顯示爲222.2而不是222.3LINQ to SQL - 十進制數據類型被截斷，而不是舍入

然後，如果我將DB中的同一列更改爲十進制（7,2），並且我不重新生成LINQ to SQL類，使用LINQ保存記錄仍然會截斷... - @ p1：輸入小數（大小= 0; Prec = 6; Scale = 1）[222.259] 數據將在數據庫中顯示爲222.20而不是222.26 （或222.30）

有沒有人知道這是否是LINQ的正確行爲？或者是SqlServer提供者？它的行爲與在mgmt studio中手動編寫查詢的方式不一樣，這就是爲什麼我對它爲什麼截斷而不是四捨五入的原因感到困惑。

在MGMT的工作室下面的查詢... UPDATE TheTable SET TheDecimalColumn = 222.259 將設置VAL至222.3當列是十進制（6,1）和222.26當它是十進制（7,2）

謝謝

來源

2009-02-20 JeremyWeir

這是sqlparameter，它必須這樣做，因爲舍入一個分數不是標準化的：有不同類型的舍入算法，用於不同類型的區域，如銀行使用不同類型的舍入標準。

如果要四捨五入，則在設置實體中的值之前，通過四捨五入來自定義它。這是合乎邏輯的，因爲你將一個數字定義爲scale，所以.256不適合單個數字，這意味着你要麼應該得到一個異常（linq to sql不支持內存驗證）或者它被截斷在較低的水平。

來源

2009-02-21 10:36:09

您是否嘗試過使用DataContext.Log從LINQ查詢中提取原始SQL？如果查詢在您通過management studio手動執行時運行，那麼提供程序可能會截斷查詢中的值。 Here's關於如何獲取原始SQL的文章。您可能還想檢查列的類型是否在.dlinq文件中正確表示。

PS- Found你的問題..小網站呃？

來源

2009-02-20 17:24:56

是的，我做了一堆測試生成的SQL，它只發生在它是通過LINQ 我認爲我完成浪費時間在這 - – JeremyWeir 2009-02-20 21:05:10

我的意思是「精度不重要」 – JeremyWeir 2009-02-20 21:05:52

我有同樣的問題。您可以控制與LINQ/EF出口數據中加入一種EntityConfiguration你的實體SQL精度：

namespace your.namespace.in.here 
{ 
    class foobarEntityConfiguration : EntityTypeConfiguration<foobarEntity> 
    { 
     public foobarEntityConfiguration() 
     { 
      this.Property(x => x.foobarPropertyBeingTruncated) 
       .HasPrecision(18, 5); 
     } 
    } 
}

由於LINQ/EF有這個bug，並作爲一般規則，我發現，保證儘可能多儘可能精確直到顯示時間是件好事。讓表示層根據需要做任何舍入/截斷。然後，如果在SQL或報告生成器中有一個LINQ導出後計算，那麼貨幣中的幾美分更有可能匹配。

請注意，在我的情況下，沒有明顯的原因，LINQ以前在截斷小數點後兩位。根據文檔，LINQ/EF根據相關小數的精度來決定。

來源

2015-09-02 14:09:32

LINQ to SQL - 十進制數據類型被截斷，而不是舍入

回答

相關問題