Форум: "Базы";
Текущий архив: 2004.01.13;
Скачать: [xml.tar.bz2];
ВнизПроблема при переходе на 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)
Если наши поля в таблице - по сути целые значения, то зачем нам считать их деньгами?
← →
Sandman25 (2003-12-17 12:08) [8][7] Reindeer Moss Eater © (17.12.03 12:04)
TBCDField хранит информацию в виде BCD.
Если вызвать BCDField.AsString, то потерь точности нет. Для отображения самое оно.
Если нужны расчеты, то нужно либо смириться с потерями точности, либо использовать AsBCD и написать пару функций (сложение, умножение) для работы с такими операндами.
← →
Reindeer Moss Eater (2003-12-17 12:10) [9]Если вызвать BCDField.AsString, то потерь точности нет. Для отображения самое оно.
Ну а если клиент селектит NUMBER в ftBCD для того, что бы потом снова передать значения на Оракл?
← →
Sandman25 (2003-12-17 12:15) [10][9] Reindeer Moss Eater © (17.12.03 12:10)
Я так и делаю, правда, для Informix.
Извлекаю DECIMAL(13,3) в ftBCD, отображаю его, пользователь его выбирает, и я передаю значение в хранимую процедуру. Параметр хранимой тоже имеет тип ptBCD. Либо вообще записываю во временную таблицу и тоже с типом DEC(13,3) и тоже Params[0].AsBCD :=
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2004.01.13;
Скачать: [xml.tar.bz2];
Память: 0.46 MB
Время: 0.008 c