|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
Сломал голову уже, помогите! С помощью процедуры в базе сохраняются суммы в колонке NUMBER(14,2). На входе процедуры - параметр P_SUM типа NUMBER. Прежде чем делать insert, процедура выполняет проверки, среди прочего есть условие: P_SUM <= MAXIMUM_ALLOWED_AMOUNT которое никогда не должно нарушаться, так как клиент автоматически подставляет корректное значение суммы в параметр P_SUM, то есть всегда вставляется максимально допустимое значение суммы. И всё было хорошо, но на днях условие стало изредка нарушаться, и исключение выбрасывается. Если походить отладчиком PL/SQL Developer-а по процедуре, то всегда всё хорошо, а вот когда пользователи вызывают процедуру через клиента - ошибка возникает часто. Ну я вставил в исключение текст Код: plsql 1.
и наблюдаю, что значение параметра P_SUM слегка неровное, что-то вроде 97.679999999930000000 или 98.680000000023000000 Мы не знаем, почему так стало, но вопрос в другом. Я подавляю исключение, записываю округлённое значение в NUMBER(14,2) и всё опять хорошо. Но! Попутно я записываю P_SUM в специально созданную тестовую таблицу в колонку P_SUM_COPY типа NUMBER(38,20). И вот любые действия с этой колонкой всегда почему-то приводят к округлённым числам. То есть to_char(p_sum_copy, '99999.9999999999999999999999999999999) возвращает всегда красивое число (98.68 например). Где-то дефект в моём понимании NUMBER, я не могу понять где. Oracle теряет точность при записи параметра в колонку NUMBER(38,20)? Или изначально в параметре 98.68, а микроскопическая прибавка - это только видимость? Как одно и то же число может быть то ровной суммой в копейках, то слегка больше, то слегка меньше? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2019, 08:31 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
MaxmixOracle теряет точностьПриведи вручную заместо оракла число 99999.9999999999999999999999999999999 к NUMBER(38,20). ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2019, 08:50 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
-2-, такого числа нигде нет, моё число предположительно 98.680000000023 Я могу вставить его вручную в колонку NUMBER(38,20), через sql*plus, и на выходе SELECT вижу 98.680000000023000000000000 После set numformat 99999999999.99999999999999999990 во-всяком случае. То есть, судя по to_char() из процедуры, там на входе параметр NUMBER имеет нецелое число копеек, после перекладывания этого NUMBER в NUMBER(38,20) с целью отладки получается целое число копеек. Как так? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2019, 10:09 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
Не пользуйтесь double для денег и будет Вам счастье. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2019, 14:49 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
andrey_anonymousНе пользуйтесь double для денег и будет Вам счастье.currency наше всё ... |
|||
:
Нравится:
Не нравится:
|
|||
09.08.2019, 15:44 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
Как-то непонятно, внутри процедуры уже нет никаких double и currency, и вот такой результат ;-( ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2019, 06:27 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
MaxmixКак-то непонятно, внутри процедуры уже нет никаких double и currency, и вот такой результат ;-(Инженера должна отличать приобретённая способность понимать и объяснять неожиданный результат. Начни свой путь с понимания того, что double вне процедуры. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.08.2019, 07:45 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
MaxmixСломал голову уже, помогите! Попутно я записываю P_SUM в специально созданную тестовую таблицу в колонку P_SUM_COPY типа NUMBER(38,20). не то вставляете (не значение параметра) Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25.
..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2019, 13:10 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
Спасибо, Stax У меня примерно такая же картина, но я думал, что мой select * from log_p_sum; врёт, показывая какие-то миллиардные доли копейки, а вот to_char() всегда говорит правду. Результат применения TO_CHAR на колонке -- круглые копейки, вот почему так? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
TO_CHAR() врёт, что ли? Куда делась точность в числе 447703.369999999995000000 после TO_CHAR? У вас колонка P_SUM_COPY такого же размера, как моя AMOUNT_PARAM то есть NUMBER(38,20)? Код: plsql 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2019, 10:34 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
Maxmixпочему так?RTFM dump() ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2019, 10:37 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
Maxmix, Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2019, 10:50 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
Maxmix, Код: plsql 1. 2. 3. 4. 5. 6. 7. 8.
.... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2019, 10:54 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7.
У нас в одинаковых колонках лежат одинаковые NUMBER, но дампы отличаются, правильно я понял? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2019, 12:40 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
Maxmix Код: plsql 1. 2. 3.
Это не может быть выводом из SQL*Plus-а. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2019, 13:10 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
Maxmix Код: plsql 1. 2. 3. 4. 5. 6. 7.
У нас в одинаковых колонках лежат одинаковые NUMBER, но дампы отличаются, правильно я понял? в табличке у Вас хранится 447703. 37 (Typ=2 Len=5: 195,45,78,4,38) откуда взялось 447703.369999999995000000 я не знаю (мож клиент глючит) Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2019, 14:18 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
Maxmixв одинаковых колонках лежат одинаковые NUMBER, но дампы отличаютсяУже сказали тебе про клиента. Код: plsql 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2019, 14:45 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
Ребята, вы круты, что выводу дампа понимаете, какое значение в базе! Теперь выясняется, что PL/SQL Developer не (всегда) показывает правильно значения NUMBER. Попутно выяснили, что to_char() показывает истинное значение. Параметр, я думаю, записываю в отладочную таблицу правильно, так как там просто insert values (... P_AMOUNT...) Далее, просмотрев накопленные значения, я вижу, что все сохранённые значения параметра уже за большой период времени вполне себе целые (в копейках). Возвращаясь к первому посту с вопросом... Тайна так и не раскрыта, почему случилось так, что в параметре оказалось нецелое число копеек. Разработчики клянутся, что галочка Currency стоит. Но, похоже, это был единичный случай! Спасибо, что не бросили! ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2019, 06:17 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
Maxmix Разработчики клянутся, что галочка Currency стоит. возможно кто-то (что-то), отработало без галочки зы самое простое - на тестовой посмотреть поведение "без галочки" ..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2019, 10:19 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
Stax, Да, проще, но только если микрокопейки будут регулярно появляться, а то вдруг есть только одна магическая сумма то будем долго тыкаться! Спасибо за помощь! ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2019, 11:59 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
MaxmixПопутно выяснили, что to_char() показывает истинное значение. У каждого своя истина. Твою похоже не смущает что TO_CHAR округляет: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8.
SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2019, 15:11 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
SY У каждого своя истина. Твою похоже не смущает что TO_CHAR округляет: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8.
SY. нет, не смущает у него в маске '999999999.99999999999999999990' "разрядов" как-бы хватает імхо зазвоздка в чем-то другом напр клиєнт не так понимает number Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
откуда пятеречка (447703.37 5 ) хз, у меня не было практики с binary_float ...... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2019, 16:34 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
Stax откуда пятеречка (447703.37 5 ) хз, у меня не было практики с binary_float Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2019, 16:43 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
Stax, причeм тут "пятерочка"? TO_CHAR дает округленное значение если дробная часть "не влезает" в маску. И почему-то это документировано не в SQL Reference Manual а в OLAP DML Reference Manual и то вскользь: Possible Effects of TO_CHAR Rounding All number format models cause the number to be rounded to the specified number of significant digits. SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2019, 17:37 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
SYИ почему-то это документировано не в SQL Reference ManualRTFM Number Format Models (FAQ) ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2019, 17:47 |
|
Точное значение NUMBER
|
|||
---|---|---|---|
#18+
SY, какой разряд (дробная часть) 447703.369999999995000000 не влезает в маску '999999999.99999999999999999990'? Код: plsql 1. 2. 3. 4. 5. 6.
..... stax ... |
|||
:
Нравится:
Не нравится:
|
|||
02.09.2019, 17:51 |
|
|
start [/forum/topic.php?fid=52&msg=39856192&tid=1882127]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
29ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 130ms |
0 / 0 |