LINQ to SQL - Десятичный тип данных усекается вместо округленного

Question

У меня есть десятичный столбец БД (6,1) При сохранении записи с помощью LINQ to SQL оно усекает значение вместо округления.

Так, например, если параметр, переданный этому столбцу в сгенерированном запросе LINQ to SQL, имеет это значение ... - @ p1: десятичное число ввода (размер = 0; точность = 6; масштаб = 1) [222.259] данные будут отображаться в БД как 222,2 вместо 222,3

Затем, если я изменю тот же столбец в БД на десятичный (7,2) и не перегенерирую классы LINQ to SQL, сохранение записи с использованием LINQ все равно будет усечено ... - @ p1: десятичное число ввода (размер = 0; точность = 6; масштаб = 1) [222.259] данные будут отображаться в БД как 222,20 вместо 222,26 (или 222,30)

Кто-нибудь знает, правильное ли это поведение для LINQ? Или это провайдер SqlServer? Это не ведет себя так же, как при написании запроса вручную в mgmt studio, поэтому я не понимаю, почему он усекается вместо округления.

Следующий запрос в mgmt studio ... ОБНОВЛЕНИЕ TheTable SET TheDecimalColumn = 222.259 установит значение val в 222,3, если столбец десятичный (6,1), и в 222,26, если он десятичный (7,2)

Спасибо

Answer 1

Это sqlparameter, и он должен это делать, так как округление дроби не стандартизировано: существуют разные виды алгоритмов округления, которые используются в разных областях, например, в банковском деле используются разные типы округления, чем в других.

Если вы хотите округлить, определите его самостоятельно, округлив значение до того, как вы установите значение в сущности. Это логично, так как вы определили одну цифру как масштаб, поэтому .256 не умещается в одну цифру, что означает, что вы либо должны получить исключение (linq to sql не поддерживает проверку в памяти для этого), либо оно будет усечено на нижних уровнях.

Answer 2

У меня была такая же проблема. Вы можете контролировать точность, с которой LINQ / EF экспортирует данные в SQL, добавив EntityConfiguration в ваш объект:

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

Поскольку в LINQ / EF есть эта ошибка, и, как правило, я считаю, что поддерживать как можно большую точность, пока время отображения не является хорошей вещью. Позвольте слою представления делать любое округление / усечение по мере необходимости. Затем, если в SQL или в построителе отчетов есть вычисления после экспорта LINQ, вероятность совпадения копеек в ваших валютах будет выше.

Обратите внимание, что в моем случае без видимой причины LINQ ранее усекался до 2 десятичных знаков. Согласно документации, LINQ / EF принимает решение на основе точности десятичных знаков.

Answer 3

Вы пытались извлечь необработанный SQL из запроса LINQ с помощью DataContext.Log? Если запрос работает, когда вы делаете это вручную через Management Studio, то поставщик может усекать значение в запросе. Вот статья о том, как получить необработанный SQL. Вы также можете проверить, что тип столбца правильно представлен в файле .dlinq.

PS- Найдено ваш вопрос .. маленький веб а?