Почему IBase не делает того что нужно???

← →
Sirus © (2002-10-16 10:13) [0]

Привет Мастера... Есть недоумение такое...
У меня есть SQL команда:
insert into SUBS_PAY (PAY_SUMM, PAY_NDS) values (123.12, 234.23)
Вроде все идет хорошо, команда выполняется 96 раз
естественно с различными values...
Но вот когда команда выполняется в 97 раз в таблицу записываются не совсем правильные данные... т.е. вместо числа 654.65 записывается 654.6499999999.... Тип поля NUMERIC(15,2)
длина неправильного числа вместе с точкой 15 символов...
Почему так происходит??? И как лечить???

← →
Johnmen © (2002-10-16 10:35) [1]

Регулярный вопрос ! :)))
Регулярный ответ - погрешность разрядной сетки....

← →
Sergey13 © (2002-10-16 10:37) [2]

Писать свою (или использовать готовую) UDF на округление и вставлять ее в тригеры. Не умеет ИБ нормально числа хранить.

← →
Johnmen © (2002-10-16 10:47) [3]

>Sergey13 © (16.10.02 10:37)
>Не умеет ИБ нормально числа хранить

Хранит абсолютно нормально !

← →
Sergey13 © (2002-10-16 11:01) [4]

2Johnmen © (16.10.02 10:47)
>Хранит абсолютно нормально !
Только клиенту отдает хреново 8-)

То-то каждую неделю этот вопрос поднимается и именно по ИБ. А вот по другим базам я что то не встречал подобных вопросов. И сам с такими траблами не сталкивался. Только на ИБ.

← →
Johnmen © (2002-10-16 11:06) [5]

>Sergey13 © (16.10.02 11:01)

Отдает, как хранит...:)))
А клиент пусть сам думает, как это понимать. :-)
Зато скорость работы с полями а-ля float максимально высока !

← →
Sirus © (2002-10-16 11:10) [6]

По моему никто не понял вопроса...
Почему в результате команды:
insert into SUBS_PAY (PAY_SUMM, PAY_NDS) values (654.65, 321.32)
Получаем в базе значения
PAY_SUMM=654.65
PAY_NDS=321.3199999999
????

← →
Johnmen © (2002-10-16 11:15) [7]

>Sirus © (16.10.02 11:10)

По-моему, ты не понял ответа...:o))

← →
Sirus © (2002-10-16 11:21) [8]

В общем если я правильно понял, то
на select SUM(FIELD) from TABLE не стоит надеятся...
Нужно вручную все суммировать и округлять...
Так???
Ну чтож... спасибо на этом... :))

← →
Sergey13 © (2002-10-16 11:26) [9]

2Johnmen © (16.10.02 11:06)
>Зато скорость работы с полями а-ля float максимально высока !
Типа приехали не туда, зато быстро. 8-)
>А клиент пусть сам думает, как это понимать. :-)
Клиент всегда прав. 8-) Если в поле есть значение 12,34 и я вычитаю 12,34, а затем запрашиваю все записи с НЕ НУЛЕВЫМ значением, то какого черта ИНОГДА (я подчеркиваю ИНОГДА) вылезает эта запись. Причем в значении этого поля гордо стоит 0, и понять причину этого появления можно только если запросить это поле умноженым на дофига. И лечится это только принудительным округлением до точности указанной в типе поля (например NUMERIC(15,2)). Другого способа я не придумал. Может подскажешь.

2Sirus © (16.10.02 11:10)
А по моему ты не понял ответов.

← →
Johnmen © (2002-10-16 11:32) [10]

>Sergey13 © (16.10.02 11:26)
>...Причем в значении этого поля гордо стоит 0,...

Нет ! Там будет стоять не 0 ! Просто тебе показывается значение уже с округлением...

>...Другого способа я не придумал...

Я тоже.. :-)

2Johnmen © (16.10.02 11:32)
>Нет ! Там будет стоять не 0 ! Просто тебе показывается значение уже с округлением...
Так в том то и трабла, что показывает не то что есть. Да и черт с ним с показом. Плохо то что условие не работает из-за этого.

Предлагаю сойтись на компромисе - хранит хорошо, но не точно. 8-)

Как я уже сказал в самом начале: тип поля NUMERIC(15,2)
Может есть другой способ....

1) Использовать 3 диалект
2) Или использовать первый диалект, но с Integer или DoublePrecision

>Sergey13 © (16.10.02 11:48)

Ок !
Кстати...Один из стандартных выходов - хранить в integer,
а в приложении интерпретировать с нужной точностью...

> Johnmen © (16.10.02 12:01)
> Ок !
> Кстати...Один из стандартных выходов - хранить в integer,
> а в приложении интерпретировать с нужной точностью...
Вот именно... Так я и сделал... Надеюсь теперь такого не повторится.... :)))

Почему IBase не делает того что нужно??? Найти похожие ветки