How can I make a c# decimal match a SQL decimal for EF change tracking?

Question

To avoid touching changeless records in EF it's important that original and current entity values match. I am seeing a problem with decimals where the EF entity has SQL representation and that is being compared to c# decimal.

This is debug output from entities with changes detected. This shows the problem pretty clearly. Even though both the entity and the source data are in of type decimal the values are considered difference even though they are equal.

How can I ensure that original and current values match when using c# decimal?

Maybe there is a way to turn the c# decimal into an entity (SQL) decimal before the update?

Another Example

I would expect the truncation to ignore the fact that the incoming precision is higher than the SQL scale

Answer 1

You could implement a proxy-property which handles the conversion from code-precision to db-precision:

public class MoneyClass
{
    [Column("Money")]
    public decimal MyDbValue { get; set; } // You existing db-property

    [NotMapped]
    public decimal MyCodeValue // some property to access within you code
    {
        get
        {
            return this.MyDbValue;
        }
        set
        {
            decimal newDbValue = decimal.Round(value, 2);
            if (this.MyDbValue != newDbValue)
            {
                Console.WriteLine("Change! Old: {0}, New: {1}, Input: {2}", this.MyDbValue, newDbValue, value);
                this.MyDbValue = newDbValue;
            }
        }
    }
}

static void Main(params string[] args)
{
    MoneyClass dbObj = new MoneyClass()
    {
        MyCodeValue = 123.456M
    };

    Console.WriteLine(dbObj.MyDbValue);
    dbObj.MyCodeValue = 123.457M; // won't change anything
    Console.WriteLine(dbObj.MyDbValue);
    dbObj.MyCodeValue = 123.454M; // will change because of 3rd decimal value 4
    Console.WriteLine(dbObj.MyDbValue);
    dbObj.MyCodeValue = 123.46M; // will change
    Console.WriteLine(dbObj.MyDbValue);
}

Answer 2

This answer is not supposed to fix exactly the issue you have, but to go around it.

I suggest to code the logic that decides whether an objects needs to be saved or not on a higher application layer (in that respect I consider the EF generated classes as low level objects).

The code which retrieves and stores data could be implemented in a repository class, i.e. a class that manages your data access logic. So what you application uses would be this repository class and not the EF code. Whether the repository class internally uses EF or something else would not be important anymore for you application. If you define an interface for you repository class you could even replace it easily with some or technology to save and retrieve data.

See here for an article from microsoft about the repository pattern. This is an info from a question here at stackoverflow.

I generally would not recommend to use the EF generated classes in normal application code. It might be tempting a first, but also cause problems later as in your case.