Проблема при переходе на Oracle c MSSQL

← →
Dmitriy (2003-12-17 11:11) [0]

При переводе на БД из под MSSQL на Oracle возникла проблема следующего плана: у Oracla нет типа int и все поля были сконвертированы во float. Но при программа, которая читает данные она читает их как integer и возникает ошибка. Можно ли этого как нить избежать? Править программу во куче мест не представляется возможным... Может быть в Оракле все таки есть что нить типа int?

← →
Johnmen © (2003-12-17 11:14) [1]

А что говорит базовая документация по этому поводу ?
:)

← →
Reindeer Moss Eater © (2003-12-17 11:18) [2]

NUMBER(X,0) - целочисленный тип на Oracle

Что бы клиент воспринимал эти поля как ftInteger нужен параметр ENABLE INTEGERS на клиенте.
Только зря все это. Лучше с такими полями работать как ftFloat

← →
bushmen © (2003-12-17 11:33) [3]

>Reindeer Moss Eater © (17.12.03 11:18) [2]
С float потери точности не будет?

← →
Reindeer Moss Eater © (2003-12-17 11:44) [4]

С float потери точности не будет?

Сам когда-то боялся этого и использовал в Delphi ftInteger.
Пока не напоролся на следущее: в чужой схеме с которой приходилось работать были ключи NUMBER(12,0). Значения для них брались из сикванса, но замешивались с некими множителями по некому алгоритму. В результате диапазон Integer (в Паскале) был исчерпан гораздо раньше, чем я предполагал. Ключи, полученные на клиента в ftInteger поля для последующей передачи обратно на сервер становились непригодными.
Выход был найден в отключении ENABLE INTEGERS и работе с ftFloat.

У Ораклового NUMBER 38 значащих цифр, а у Паскалевского DOUBLE - 16. Так что с потерей точности все в порядке.

← →
Dmitiry (2003-12-17 11:45) [5]

Да можно было работать как c float, но уже есть написанная программа и переделывать ее нет никакого желания
По поводу NUMBER нужно посмотреть

← →
Sandman25 © (2003-12-17 11:54) [6]

[4] Reindeer Moss Eater © (17.12.03 11:44)

Почему не использовать TBCD или TFMTBCD? Ни потери точности, ни проблемы с переполнением INTEGER. У нас в БД половина ключей состоит из DEC(13,3), без FMT ничего не получилось бы.

← →
Reindeer Moss Eater © (2003-12-17 12:04) [7]

Ну большой разницы нет, если учесть что
Delphi does not have a native type for BCD. Therefore, TBCDField converts the data from a BCD value to a Currency

То есть если иметь ftBCD то имеем два пути:
AsFloat (получаем DOUBLE значение)
AsCurrency (получаем Currenсy)

Если наши поля в таблице - по сути целые значения, то зачем нам считать их деньгами?

[7] Reindeer Moss Eater © (17.12.03 12:04)

TBCDField хранит информацию в виде BCD.
Если вызвать BCDField.AsString, то потерь точности нет. Для отображения самое оно.

Если нужны расчеты, то нужно либо смириться с потерями точности, либо использовать AsBCD и написать пару функций (сложение, умножение) для работы с такими операндами.

Если вызвать BCDField.AsString, то потерь точности нет. Для отображения самое оно.

Ну а если клиент селектит NUMBER в ftBCD для того, что бы потом снова передать значения на Оракл?

[9] Reindeer Moss Eater © (17.12.03 12:10)

Я так и делаю, правда, для Informix.
Извлекаю DECIMAL(13,3) в ftBCD, отображаю его, пользователь его выбирает, и я передаю значение в хранимую процедуру. Параметр хранимой тоже имеет тип ptBCD. Либо вообще записываю во временную таблицу и тоже с типом DEC(13,3) и тоже Params[0].AsBCD :=

Проблема при переходе на Oracle c MSSQL Найти похожие ветки