Симонов ДенисЕсли нет аналога в старом, то придётся в новое лезть, только и всего.

но речь шла про int128 - а его вроде бы уже протащили в старый API, во всяком случае константы sql_type цитировали

Симонов Денис,

посмотрю, как во времена Delphi 5 или Delphi 2006 переводили int64 в TField.AsDouble и сделаю аналогично

а с твоим хелпером будет аналогичная проблема, как скопировать данные из поля в байтовые буфера "текущая запись плюс-минус пара десятка строк, чтобы на экран влезало" у TDataSet

Только копировать надо будет не из SQLDA, а из твоего хелпера.

Симонов Денистам есть поле типа FMTBcd в него можно закатать.

агась, в него родного и закатывали. До сих пор хвосты попадаются в старой прикладухе, которая начиналась с BDE/Paradox через BDE/IB5/Dialect1 и в dbx/Firebird/Dialect3

Вариант 1. Берём указатель из SQLDA и вызываем в хелепере функцию toBcd, если она бинарно совместимо, то следом function BcdFromBytes(const AValue: TArray<Byte>): TBcd;

Ё! ещё и указатель надо взять не НА DA, а ИЗ DA. Т.е. DA придётся руками парсить. К вопросу о полезности хелперов, которые по идее должны превращать низкоуровневый опасный код в высокоуровневый безопасный.

Кстати, спасибо за наводку. Глянул я внутрь этой функции.... buffer overrun на чтение. Размер входного буфера никто не проверяет. И вообще всё, что она делает по сути - это один вызов Move (memory copy), только расписанный на три раздельных операции, чтобы подольше исполнялось. Характерно, что в списке typecast'ов у TBcd этого мрака нет. Видимо осталось с каких-то совсем древних времён чисто ради совместимости. Возможно, ради совместимости с .Net.

В общем, если там и делать Delphi helper, то возвращать он должен не TBytes (неформатированный дамп который может совпасть по длине и внутреннему содержимому с TBcd, а может и не совпасть), а сразу готовый TBcd. И не по указателю "из" SQLDA, а "на" SQLDA. Иначе смысла в таком хелпере не много остаётся.

А сейчас получится, что для доработки TDataSet у нас будет
1. самостоятельная привязка к буферам, TFieldDefs и прочей внутренней кухни TDataSet
2. самостоятельный парсинг низкоуровневой структуры XSQLDA (с проверкой на dialect 0 SQLDA)
3. дёрганье хелпера, создающего "сырой" дамп в TBytes - ARC-структуре, т.е. запускающего две глобальные блокировки потоков процессора, как минимум две.

"В таком аксепте" я бы этим хелпером пользоваться не стал, а либо выдрал из него код копипастом (это хоть какое-то, но использование), а вероятнее таки написал бы сам на основе ib6 api guide. Потому что на фоне 1 и 2 экономия усилий от его использования небольшая, при этом возникает ИЛЛЮЗИЯ высокоуровневого безопасного кода плюс ненужные блокировки.

Мимопроходящий04.10.2019 22:10, Dimitry Sibiryakov пишет:
> вторая половина FireDAC-а, так называемый "физический слой".

вот за это я его и не люблю.
даже кушать не могу! (С)

Ну так - оно всё такое. И вообще, как делать унифицированный интерфейс без abstraction layer, как ты его не назови?

DBX - в качестве "физического слоя" используется "провайдер" с закрытыми исходниками и минимумом документации, написанный вокруг COM-модели, с вероятной целью унифицировать нативный и .NET-ный Delphi

Что интересно, китайцы написали альтернативный Firebird DBX Provider - но исходников так же не выложили.

BDE - в качестве "физического слоя" выступает сам BDE. С закрытыми исходниками, изначально рассчитанный на ISAM с SQL прикрученным "сбоку бантик" задним числом, давно не поддерживаемый, по факту почти не совместимый с современными Windows, и гораздо более сложный (кто-нибудь видел сторонний drop-in replacement для BDE?)

Я таки тоже не вижу смысла в претенизии к AnyDAC с этой стороны. Разве что как завуалированную претензию к универсальности AnyDAC. Ну так если кому-то нужно "close to metal" - то есть и UIB и IBX

Симонов ДенисЧто в BDE есть такого чего нет в FireDac?

прямая работа с файлами Paradox

"Плюшки за 15 лет" для "нуба", которому надо "начинать разработку на Firebird" - они сильно overrated

логиновские FB IBX Utils никто не отменял, если "нуб" по инерции с IBX начнёт.

UIB в режиме Firebird 2.5 даст всё, что нубу будет нужно в ближайшие пару лет.
Включая такую приятную мелочь, как вычитывание запросов в виде



К сожалению, из за убогого полуживого type inference в Delphi тип переменной надо явно объявлять, иначе бы ещё красивее было.

И какой такой killer feature при этом лишится "начинающий разработку" "нуб" ?