Был удивлен, когда по результатам отчетов не сходились копейки, и, проведя эксперимент, получилось, что FastReport использует в форматировании банковское округление.
Значение 39,065 превращается в 39,06 при форматировании вида %2.2f.

чччДsvnvlad,

Просто ты почему-то решил, что в исходных числах ("до округления") всего 4 знака после десятичной точки.
А там - не 4 ;).
Там 4.

А вот то же самое число без округлений и форматирования: 815039,06501

BANK_ROUND здесь - хранимая функция. Не смущайтесь, можно ее заменить на ROUND, суть не в этом. А то, что там на входе отчета 4 знака.

чччД,

провел эксперимент:


Без форматирования отчет выводит эти же цифры 1.55 и 1.65.

Затем задаю формат вывода с 1 знаком после запятой:

и вуаля!

Котовасиядробные десятичные числа нельзя точно представить в двоичной форме.
И что там выводится - дело второе, главное - что там хранится.
Так устроит?


А результат одинаковый: 1,6

к слову, в базе у меня все поля с дробной частью - такого типа: DECIMAL(11, 5)

Да и какая разница, если два способа, примененные к одному и тому же числу, выдают разный результат?
1. Если округлять в SQL-запросе:


Выдает 1,7.

2. Если округлять
в FastReport-е, назначая формат %2.1f, получается 1,6.

Фаст репорт округляет по-банковски.

по факту FR все четные 5 округляет в меньшую сторону, нечетные - в большую.

_DenZ__svnvlad,

По факту, FR ничего не округляет, метод округления зависит от типа и установленного флага.



fixed-формат делает банковское округление?

чччД_DenZ__... в итоге поле Double типа ?
Такое число в любом случае будет представлять приближение исходного числа в вещественном типе. Для Double - 815039,06501 будет что-то вроде 815039,06499999999...
+1.
BCD, или Сurrency.

Однако, тут дело бесполезное, человек про внутреннее представление знать не желает, хотя его уже трижды в одно место носом ткнули.
Все так, внутреннее представление и т.д. Но на практике все работает так, как будто это четкое банковское округление. В итоге нужны практические последствия, внутреннее представление заказчика не интересует. Неужели это не повод уделить внимание такому феномену, чем его не глядя отметать, т.к. в теории это "не работает"?

_DenZ__svnvlad,

Какого типа TField у TDataSet ?
Неизвестно. Типы полям не назначал, просто подключаю TADQuery к TDataSource и frxDBDataset и frxReport.
Само поле DECIMAL.

Dmitri Krizhanovski, нет.

Dmitri Krizhanovskisvnvlad,

TUniQuery (select 1.65 as uttt) к TDataSource к frxDBDataset и frxReport (DisplayFormat(FormatStr='%2.1f', Kibnd=fkNumeric)) = 1.7


Да, оказалось не всегда. С числом 59641,155 осечка вышла, фаст репорт округлил до 59641,15

DimaBrFastReport использует функцию Format().
У тебя претензии к Fastу, к Функции или к жизни ???
Претензий не было, наоборот, обрадовался, что фаст репорт округляет уже так как надо. Но оказалось, не всегда. Придется в самом запросе уже округлять до необходимого разряда, и выводить готовые.