iBase.ru Forum

Здравствуйте! Может кто то работал с полями типа bigint посредством dataset'a фибовского ? Как таковой, тип bigint явно ими не поддерживается, кто как решал вопрос корректной работы с bigint? Я например привожу поля к строковому виду (dataset->FBN"field"->AsString) , a затем преобразование StrToInt64. Но тут возникает одно но! Необходимо дополнительно обрабатывать NULL в полях. Может есть более красивый способ?
p.s. fib+ 6.45 builder c++ 5.0 .
p.p.sFIBQuery в моём случае для работы не подходит.

Чо-т я не понял. Ты предлагаешь нам саппорт фибов сюда позвать? А мож таки сам туда сходишь?

Сам спросил и сам ответил
Есть класс TFIBBCDField, А в нём AsInt64. Посему делаем так :
((TFIBBCDField*) FibDataSet->FBN("field"))->AsInt64. И всё должно быть в шоколаде. Или и тут какие нибудь грабли есть?

что, идентификаторы BIGINT делаем? А назвать число, помещающееся в BIGING, слабО?

Не помню цифр, но помню что ооооооочень большое. Собственно умом я понимаю что пока вряд ли мои числа перешагнут рубеж обычного Integer, но хочется порядка, и если максимальное число которое можно записать в ячейку БД - 64 бита, то и клиент пускай целиком тянет 64 бита . Да и обидно будет если всё-таки в дальнейшем порядки чисел изменяться и из-за того что не учёл этого на клиенте, будет идти некорректная работа программы.
2 Merlin : На саппорт фибов написал первым делом, и ответ получил причём достаточно полный, а сюда написал чтобы узнать другие решения если они есть

объясняю. если ты НЕ УВЕРЕН в том что по идентификаторам не перешагнешь 4 миллиарда, то НИ В КОЕМ СЛУЧАЕ идентификаторы (первичные ключи) не надо делать BIGINT. От этого только один гемор. А если этот гемор не оправдан...

на всякий случай, пример из области генераторов - когда они были 32-разрядные, генератор мог кончиться через 25 лет (!) если каждую секунду (!) генерить по 3 новых (!) идентификатора.

просто я смотрю на новых базоданностроителей - как увидят bigint, сразу его влупляют как ПК не раздумывая. А сами макс число назвать не могут

paratruper писал(а):Собственно умом я понимаю что пока вряд ли мои числа перешагнут рубеж обычного Integer, но хочется порядка, и если максимальное число которое можно записать в ячейку БД - 64 бита, то и клиент пускай целиком тянет 64 бита .

Если ты умом понимаешь, что 64 бита тебе не надо, то чем ты принимаешь решение работать с BigInt? Подсознанием? Надсознанием? Или мозжечком?

ему хочется чтобы было "красиво". А bigint - это красиво. Enlarge your ..., извините за выражение. я другой мотивации не вижу.

Могли бы вы пояснить какой гемор будет с bigint, или показать ссылку где это описано? Честно говоря не могу понять какой тут гемор? Серъёзно. Единственное что приходмт на ум это проблемы работы с такими числами на клиенте, но их я и пытаюсь тут выяснить Если поделитесь информацией по этому поводу - буду благодарен.
2 CyberMax %) Тут ключевое слово "пока" Сейчас действительно мне хватает integer, однако на данном этапе, работа прораммы происходит на одном рабочем месте (обкатывется), а в итоге, этих мест будет порядка 20-30. И хотелось бы иметь на каждом месте гарантированно уникальные идентификаторы в одном общем диапазоне, для более-менее корректной репликации. Вот в принципе главный аргумент для выбора bigint.

для более-менее корректной репликации. Вот в принципе главный аргумент для выбора bigint.

т.е. ты даже считать не стал. наобум ляпнул, и все.

Честно говоря не могу понять какой тут гемор?

ну так ведь уже? Или топик создан зачем?

kdv писал(а):

для более-менее корректной репликации. Вот в принципе главный аргумент для выбора bigint.

т.е. ты даже считать не стал. наобум ляпнул, и все.

Честно признаюсь посчитать поленился, теперь прикинул - действительно возможно и int хватит....
Теперь вот думаю чем меня ещё по голове стукнет bigint...