ХП. В чем разница?

← →
TohaNik_ (2004-05-11 19:08) [0]

RETURNS (
COURCE NUMERIC(10,6),
SCALE NUMERIC(10,2),
........
AS
DECLARE VARIABLE PRICE NUMERIC(15,2);
DECLARE VARIABLE SUMAT_UAH NUMERIC(15,2);
DECLARE VARIABLE T_KOL NUMERIC(15,3);
.......
на момент выполнения выражения значения
COURCE = 7,4;
SCALE = 1;
PRICE = 4000;
T_KOL = 302,601;

так SUMAT_UAР = ((PRICE*COURCE)/SCALE)*T_KOL;
в результате: Integer overflow

так SUMAT_UAH = PRICE*COURCE*T_KOL;
SUMAT_UAH = SUMAT_UAN/SCALE;
все нормально

А если PRICE = 3000; ошибки нет в обоих вариантах??

← →
Курдль © (2004-05-12 00:20) [1]

А запятые в константах глаз не режут?

← →
TohaNik_ (2004-05-12 10:31) [2]

> А запятые в константах глаз не режут?

Не придирайся.
Как оказалось Yaffil не Delphi

← →
Johnmen © (2004-05-12 10:33) [3]

>TohaNik_ (12.05.04 10:31) [2]
>Как оказалось Yaffil не Delphi

А раньше думал иначе ?
:)))

← →
sniknik © (2004-05-12 10:52) [4]

> Как оказалось Yaffil не Delphi
;о)))
класс... (без обид, но это действительно весело)
кстати в любом другом движке в SQL тоже не используются запятые для отделений дробной части, т.к. запятые зарезервированы для разделений полей в командах (select/...).
иногда на это напарываются когда запросы динамически составляют, (значения прям в запрос) а функции перевода чисел в строки зависят от национальных установок/desimalseparator а SQL нет. потом "у меня на машине работает, а у соседа васи винда/sql сервер глючит! мне что его переставлять?"
:о) тоже весело.

← →
TohaNik_ (2004-05-12 13:21) [5]

> класс... (без обид, но это действительно весело)

Нет, про запятые и точки я знаю(ну опечатка была).
Оказалось еще веселей
CREATE PROCEDURE NEW_PROCEDURE
AS
DECLARE VARIABLE A numeric(15,3);
begin
A = 4010.00*7.400000*30.601/1.00; нет ошибки = 908054.078
A = 4100.00*7.400000*30.601/1.0; нет ошибки = 928434.34
A = 4100.00*7.400000*30.601/1.00; ошибка
end

← →
Курдль © (2004-05-12 13:27) [6]

Мож забить на numeric и прописать, как float (если Yaffil позволяет)?

← →
TohaNik_ (2004-05-12 13:45) [7]

> Мож забить на numeric и прописать, как float (если Yaffil
> позволяет)?

Мож и забить -вообще)), только дело наверное в хранении результата до того
как он стал - A

← →
Johnmen © (2004-05-12 13:52) [8]

>TohaNik_

>A = 4100.00*7.400000*30.601/1.00; ошибка

Полный текст ошибки ?

Какой диалект ?

А так проходит ?
A = 4010.0*7.4*30.601/1.00;
A = 4100.0*7.4*30.601/1.0;
A = 4100.0*7.4*30.601/1.00;

← →
TohaNik_ (2004-05-12 14:10) [9]

> Полный текст ошибки ?

Arithmetic overflow or division by zero has occured
arithmetic exception, numeric overflow, or string truncation

> Какой диалект ?

третий

> А так проходит ?

проходит

Понятно...
Дело в том, что numeric больший (9,2) храниться как bigint.
При разборе выражения учитывается точность представления. Причем "суммарно" "приведённая" к bigint с учетом всех переменных/констант.

Поэтому следует указывать только один разряд после дес.тчк, если в большем нет необходимости.

← →
TohaNik_ (2004-05-12 14:51) [11]

> Johnmen © (12.05.04 14:17) [10]

Спасибо.

CREATE PROCEDURE NEW_PROCEDURE
AS
DECLARE VARIABLE A numeric(15,2);
DECLARE VARIABLE B numeric(10,6);
DECLARE VARIABLE C numeric(15,3);
DECLARE VARIABLE D numeric(15,2);
DECLARE VARIABLE E numeric(15,2);

begin
B = 7.4;
C = 30.601;
D = 4100;
E = 1;
A = D*B*C/E; ошибка

A = D*B*C;
A = A/E; нет ошибки
end
Реальная процедура отлаживалась в IB Expert - у переменных нули
при отладке усекались, а реально вероятно было
>> "суммарно" "приведённая" ...
Насколько я понял - при построении выражений необходимо следить
за возможной "суммарно" "приведённой" к bigint точностью.

>TohaNik_ (12.05.04 14:51) [11]

Я думаю, что это всё-таки проблемы дятловского парсера, его фича...:)

> Реальная процедура отлаживалась в IB Expert

Кстати, не вспомню, почему именно, но от применения IB Expert при подготовке БД Yaffil-а я отказался (все время лезли баги). Пришлось воспользоваться стандартным IB Console-м и его тулзами.

ХП. В чем разница? Найти похожие ветки