Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 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.47 MB
Время: 0.01 c
1-37785
Mike_forewer
2003-12-27 19:36
2004.01.13
Фон в MainMenu


6-37814
SkyN
2003-11-14 16:27
2004.01.13
Как узнать, к какому ресурсу подключен сетевой диск


14-37861
REA
2003-12-22 16:47
2004.01.13
COM -> TCP/IP -> COM


3-37566
List
2003-12-12 00:01
2004.01.13
Data Module


14-37909
Style
2003-12-23 11:38
2004.01.13
Немного о TCollection??





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский