numeric(11,0)

← →
GanibalLector © (2004-06-14 19:38) [0]

Предположим,что в некой таблице существует поле tel - numeric(11,0).И есть хранимая процедура,которая добавляет(ну,или изменят) эту таблицу.Так вот,а как писать в Delphi,при таком формате поля???
Следует отметить,что в DataType у него ftLargeint .
Что я только не пробовал и strtofloat и strtoint64 и просто число.Никак!!!Всегда ошибка-Unsupported feature.Вот,единственное,что проходит
IBStoredProc1.ParamByName("tel"):=null
но мне это не подходит.Что посоветуете???
З.Ы. alter не предлагать.

← →
kaif © (2004-06-14 19:57) [1]

Я только что воспроизвел эту ситуацию. Действительно, поле Largeint. Я попробовал метод AsInteger. Нормально работает.

← →
Johnmen © (2004-06-14 20:17) [2]

Понятно. Если большое целое, то значит 3 диалект.
Следовательно в обязательном порядке апдейтить IBX.

← →
GanibalLector © (2004-06-14 20:57) [3]

2 kaif
Спасибо.
А вообще,странно,это все :
IbstoredProc1.ParamByName("P_A5").asinteger:=4;//работает
IbstoredProc1.ParamByName("P_A5").value:=4;//не работает

2 Johnmen
>Следовательно в обязательном порядке апдейтить IBX.
Дык уже.

← →
GanibalLector © (2004-06-14 21:00) [4]

М-да,но !!! numeric(11,0) предполагает,что у меня число отнють не integer.

И это IbstoredProc1.ParamByName("P_A5").asinteger:=80679217355;
приведет к ошибке!!!
Так что,asinteger не выход из ситуации.

← →
Anatoly Podgoretsky © (2004-06-14 21:02) [5]

kaif © (14.06.04 19:57) [1]
Не может это нормально работать, поскольку интегер это примерно 2E9

← →
kaif © (2004-06-14 21:17) [6]

И это IbstoredProc1.ParamByName("P_A5").asinteger:=80679217355;
приведет к ошибке!!!

А Вы уже попробовали или пока предполагаете?
А AsInt64 есть такой метод? У меня нет под рукой Delphi сейчас.

← →
GanibalLector © (2004-06-14 21:19) [7]

>А Вы уже попробовали или пока предполагаете?
Пробовал конечно.

>А AsInt64 есть такой метод?
Не,такого нет.

← →
kaif © (2004-06-14 21:21) [8]

Честно говоря у меня такое подозрение, что это номер телефона.
Я бы не стал его делать как numeric(11,0). Так как потом я попросту не знал бы как SQL-запросом получить все "московские номера". Так что тот, кто решил использовать такие странные типы полей пусть и объясняет, как он дальшен собирается с ними работать. Тем более, что никакой разницы между int64 и numeric(11,0) я вообще не вижу. Так что здесь много бессознательного программирования, а когда имеется такое дело, то каждую секунду будут новые прооблемы.
Давайте по-порядку.
1. Что в этом поле должно храниться?
2. Почему выбран именно этот странный тип данных, а не decimal, к примеру?

← →
GanibalLector © (2004-06-14 21:33) [9]

>Что в этом поле должно храниться?
Ну да телефон
>Почему выбран именно этот странный тип данных, а не decimal, к >примеру?
а потому,что decimal=numeric!!!В киге написано,не я выдумал.И автор рекомендует numeric.Вот я и решил...

← →
Анатолий Подгорецкий © (2004-06-14 21:37) [10]

Есть свойство AsLargeInt

← →
jack128 © (2004-06-14 21:42) [11]

> Дык уже.

то что я тебе кинул - этот последний апдейт для Delphi5(!!!) (для старших версий Делфи есть более поздние апдейты). Больше, насколько я знаю, Delphi5 разработчиком IBX НЕ поддерживается.

> а потому,что decimal=numeric

> И автор рекомендует numeric
:-)) Задать бы вопрос этому автору (чую - это Ковязин и Востриков), если это одно и тоже, то почему именно нумерик?

>Есть свойство AsLargeInt
У мя Undeclared Identifier т.е. нету AsLargeInt.

З.Ы. Ну ладно,пусть хоть decimal.И как его писать?asvariant?
Уж больно не хочется делать телефон varchar-ом.

Попробуй как AsVariant. Может последние IBX схавают. И еще потыкай исходный текст IBX в части реализации методов типа ParamByName в TIBCustomDataSet. Там наверняка много интересного найдешь, может быть и хвосты, как эту проблему с largeint решать. Я бы сам посмотрел, но нет текста сейчас под рукой.
А насчет того чтобы не делать его varchar-ом я бы еще подумал...
Я бы все же разделил код города и номер.
Смотри, например, мой мобильный федеральный номер при наборе с города звучит так:
8-911-XXX-XX-XX
А при наборе с мобильного звучит так:
+7-911-XXX-XX-XX
Так что если ты его запишешь в свою базу как
8911XXXXXXX
возможно, он и поместится, как numeric(11,0).
Но я бы подумал все же, прежде, чем поступать именно так. Особенно если завтра объявят о переходе с 8 на 7 при наборе с городского телефона.
Или если ты захочешь выдрать все вологодские номера, как ты SQL-запрос будешь писать? Или если захочешь построить отчет-пирог типа:
SELECT CITY_CODE, COUNT(*)
FROM PHONES
GROUP BY CITY_CODE

а иногда полезно бывает делать такие запросы. Особенно, когда заказчик с ножом к горлу пристает. Если в информации скрыта структура, лучше ее выявить. А то зачем вообще все эти базы данных, поля и индексы? Возьми поле BLOB и пиши туда хоть 300-разрядный номер телефона.

Кажется, я нашел подходящее решение. Используй метод AsBCD. Если не сработает с numeric(11,0) измени тип поля на decimal(11,0).
Метод AsBCD гарантирует, что все числа будут иметь формат int64. И этот метод поддерживается компонентами IBX очень хорошо. Я его сам часто использую. Просто он не пришел мне сразу в голову, так как мне кажется, что эту задачу (хранение номеров телефонов) не стоит так решать, а стоит отделить все префиксы от номера и хранить их в отдельных полях:
1. Используется ли выход на междугороднюю линию
2. Код города
3. Номер
Примерно так, как сделано в настройке модема в Windows.
Хотя - дело хозяйское. Задача полностью известна лишь тебе.

Наконец, есть еще последний вариант. Самый странный, но он обязательно сработает. Используй метод AsCurrency.
Итак:
AsBCD или AsCurrency. Оба метода дадут тебе до 15 десятичных знаков точности. Но AsBCD как-то лучше смотрится в данном случае. Просто я не помню, работает ли он с объектами типа "параметр хранимой процедуры". Вот с объектами класса TIBBCDField он точно работает.

numeric(11,0) Найти похожие ветки