2014-01-21 3 views
0

Надеюсь, кто-то может помочь! Мы сталкиваемся с проблемой с контролем Pervasive VAccess, когда в любой момент, когда мы сохраняем элемент типа «double» в базе данных Pervasive, сохраненное значение отличается от того, которое мы хотим ...Pervasive VAccess control v двойной тип данных

В качестве примера мы пытаемся чтобы сохранить 1,44 и это на самом деле экономит 1,44004035454

небольшая разница, но разница, тем не менее!

FYI Поле, определенное в DDF, имеет десятичное значение, равное 0, мне интересно, должен ли один курс действий установить это, например. 4? Но я думал, что посмотрю, сможет ли кто-нибудь пролить свет на него, прежде чем мы опустим этот путь ...

ответ

0

Основной эффект не имеет ничего общего с распространенным, это a simple floating point issue. Вы найдете то же самое в любой системе, которая использует плавающие точки с двойной или двойной точностью, хотя некоторые системы выполняют автоматическое округление, чтобы скрыть это от вас.

http://en.wikipedia.org/wiki/Floating_point См

В случае PostgreSQL и его производных, вы можете установить extra_float_digits контролировать это округление.

regress=> SET extra_float_digits = 3; 
SET 
regress=> SELECT FLOAT8 '1.44'; 
     float8   
--------------------- 
1.43999999999999995 
(1 row) 

regress=> SET extra_float_digits = 0; 
SET 
regress=> SELECT FLOAT8 '1.44'; 
float8 
-------- 
    1.44 
(1 row) 

По умолчанию 0, но ваш драйвер клиента может его изменить. Если вы используете JDBC (который, как я предполагаю, вы есть), не связывайтесь с этим параметром, драйвер JDBC ожидает, что он останется тем, как его устанавливает драйвер, и будет вас расстраивать, если вы его измените.

В общем случае, если вы хотите, чтобы читаемый форматированный номер был человеком, вы должны делать округление с round или to_char или вместо этого делать это на стороне клиента. Обратите внимание, что нет функции round(double precision, integer) по причинам, описанным ниже in answers to this question. Поэтому вам, вероятно, понадобится to_char, например.

regress=> SELECT to_char(FLOAT8 '1.44', 'MI999999999D99'); 
    to_char  
--------------- 
      1.44 
(1 row) 

(Я хочу PostgreSQL разоблачил версию отлитого из float8 в text, которые позволяют вам указать extra_float_digits на основе каждого вызова. Это часто ближе к тому, что люди действительно хотят. Думаю, я должен добавить, что если я получаю время ...)

+0

Обратите внимание, что OP использует Pervasive engine engine (http://en.wikipedia.org/wiki/Pervasive_PSQL) NOT Postgres –

+0

@MattWilko Да, как я отметил в первом параграфе. Для этого было бы неважно, если бы они использовали Python, общий принцип все же применяется. Поплавки неточны, поэтому то, что вы храните, не обязательно означает, что вы вернетесь, и вы должны округлить и отформатировать их для пользовательского отображения. –

+0

Согласитесь со всем, что моя точка зрения заключалась в том, что 'extra_float_digits' не будет распознаваться в Pervasive PSQL –

Смежные вопросы