denis_viktorovich...
Кто нибудь знает изз-за чего это и как бороться?
Из-за double. Сделай тип NUMERIC(8.2)

Если кратко: double хранится в двоичном виде с плавающей запятой и при преобразовании того что после запятой 100% точности не получается, ошибка в 7-8 знаке. Вот погрешность и вылазит. Старинная проблема, из-за нее тип CURRENCY (он же MONEY) придумали, двоично-десятичную систему в процессоры добавили.

double можно использовать когда разброс значений огромен, а погрешность не принципиальна, т.е. ошибка в 7-8 знаке. В твоем случае вероятно ошибка накопилась ранее, т.к. пример PaulWist ее не подтверждает.

Твоя смена формата туда-обратно провела пересчет, но проблема вылезет снова. Используй тип NUMERIC(8.2)

denis_viktorovichПричем при следующем расчете все повторяется. Както интересно файл портится, отображается нормально, а при суммировании обрезает.
он не портится, это особенность формата double

denis_viktorovich... Интересно, задача не мной написана и почемуто раньше не обращали внимания на это. .....
Раньше техника послабее была, винты поменьше, памяти меньше, сетка 10мбит ... Поэтому всеми способами старались минимизировать объем хранимых данных для повышения производительности. Хотя это и сейчас актуально, может не так сильно. Может разработчик и знал о проблеме, но счел ее менее важной чем снижение производительности.

С NUMERIC тоже можно на копейках попасться:
ответ будет 107.90, а не 107.91 как ожидается.
Проблема в значении 102.71 оно не влазит в N(5,2) и сохранится как 102.7 и ошибки переполнения никакой при этом не будет.

Для денежных сумм специально придумали еще тип CURRENCY (в MS-SQL MONEY), обрабатывается как восьмибайтное двоичное целое, отображается со сдвигом на 4 десятичных знака, нет никаких погрешностей при сложении, вычитании, умножении, но есть подводные камни при делении (результат до 4-х знаков после запятой округляется). т.е. 1.2345 / 100 * 100 => 1.2300

Надо просто все это знать перед тем как использовать.

PaulWist Dima T
Проблема в значении 102.71 оно не влазит в N(5,2) и сохранится как 102.7 и ошибки переполнения никакой при этом не будет.


Э-э-э, скорее это не проблема, а "забывчивость", те Вы пытаетесь в 5 знаков 4 цифры+точка запихнуть число из 6-ти знаков.
Какой ты догадливый Не надо буквально воспринимать примеры, они простые только для того чтобы их легко понять было, проявляй немного фантазии :)

Реально было так (лет десять назад). В проге была оборотная ведомость по покупателям (остаток, отгружено, оплачено), которая предварительно сохранялась в курсор, поля сумм были N(10, 2) т.е. до 10 млн.р. разрядности хватало. И в один прекрасный дель появился контрагент, по которому оборот перевалил за 10 млн.р., копейки обрезались, а т.к. остаток на конец считался как остаток на начало + приход - расход, то этот конечный остаток не совпал с остатком на начало следующего периода (который считался правильно). На 3 копейки, мне тогда главбухша долго эти три копейки забыть не могла, они там отчеты все в налоговую посдавали, дотошная попалась :)

После того случая для денег мне больше тип MONEY нравится.