дома дельфи нет, только предположения:
проблема может быть в том, что IBX не считает insert за выборку данных, поэтому принудительно Eof выставляет в false для такого запроса. С другой стороны сервер таки отдает данные, поэтому FieldByName таки правильно возвращает данные

> проблема может быть в том, что IBX не считает insert за
> выборку данных, поэтому принудительно Eof выставляет в false
> для такого запроса. С другой стороны сервер таки отдает
> данные, поэтому FieldByName таки правильно возвращает данные


Ну я тоже так думаю. Совсем забыл, что в IB надо селект из ХП делать, это и смутило.

> Ega23 ©   (24.01.12 16:17)
>
> Так вот. Не работает. Но, как только убираем строчку if
> not Eof - получаем сообщение с правильным id.
>

Дело в том, что НД в результате выполнения запроса нет. Значит Eof=True, Bof=True. И First не только не поможет, но и неприменим.

> но и неприменим.
FieldByName
?

> Johnmen ©   (26.01.12 22:09) [22]
>
>
> > Ega23 ©   (24.01.12 16:17)
> >
> > Так вот. Не работает. Но, как только убираем строчку if
> > not Eof - получаем сообщение с правильным id.
> >
>
> Дело в том, что НД в результате выполнения запроса нет.

"христом-богом" клянусь, что у меня была та же самая проблема с TIBSQL при запросе типа "select".

ИМХО, он просто не инициализирует возвращаемый рекордсет, в датасете позиция не устанавливается на запись, и "смотрит" за... FieldByName работает как положено, оно при "выходе" указателя за "смотрит" в последнюю запись (иначе бы не работали после циклов с while not eof do, а они работают...)

не знаю просто про TIBxxxx, но в ADO рекордсет возвращается всегда (кроме случая когда отключен опцией)... не как набор данных, но как информационная структура, с ошибками, сообщениями, out параметрами. т.е. как бы обьект содержащий и рекордсет в том числе.

> sniknik ©   (26.01.12 23:15) [23]
> > но и неприменим.
> FieldByName
> ?

FieldByName применим.

> Германн ©   (27.01.12 02:43) [24]
> "христом-богом" клянусь, что у меня была та же самая проблема
> с TIBSQL при запросе типа "select".

Так дело не в select,  а в пустом НД.

> Ega23 ©   (26.01.12 13:07) [14]

А по этому поводу (я о причинах перехода): разработчики FIB+ утверждают, что будут поддерживать API как IB, так и FB... + у них реализована эмуляция логических поле (как и в примере, с созданием домена), GUID ... и многое другое.. например, 2 транзакции: одна длинная на чтение, короткая - на запись, локальная сортировка по нескольким полям, режим ограниченного чтения буфера данных(что очень приятно на больших НД), кэш БЛОБ полей на локальный диск(если меняется хэндл блоба, перечитывается, иначе БЛОБ читается с локального диска), возможность подключить функцию сжатия/распаковки для БЛОБ-полей (в итоге уменьшается трафик по сети. В отличии от фильтров самого сервера, данные пакуются и передаются на сервер уже в меньшем объеме. И наоборот, распаковываются уже на клиенте). Для мастер-детали возможно автоматического открытия мастера, задержка в открытии детали(если бежишь по приличному НД, не открывается каждый раз деталь, что экономит время).. И т.д.

> Так дело не в select,  а в пустом НД.
в данном случае, одна запись в наборе есть, иначе бы вместо
>  ShowMessage(FieldByName('id').AsString);
>  ... получаем сообщение с правильным id.
получили пустую строку.

> sniknik ©   (27.01.12 20:09) [29]
>
> > Так дело не в select,  а в пустом НД.
> в данном случае, одна запись в наборе есть, иначе бы вместо
> >  ShowMessage(FieldByName('id').AsString);
> >  ... получаем сообщение с правильным id.
> получили пустую строку.

В оригинале:


(здесь пропущен then)
Но, как только убираем строчку if not Eof - получаем сообщение с правильным id.

понятно, ты считаешь, ошибка не опечатка, и Ega23 конечно ни в жизнь не разберется с сообщением о неверном синтаксисе... (сарказм)
но не надо игнорировать суть моего сообщения. вот убрали, ошибки нет, и значение ВОЗВРАЩАЕТСЯ, правильное, что без заполненного хотя бы одной записью набора невозможно. (вот если бы там вместо FieldByName стоял ParamByName другое дело)

Дело в том, что возвращаемые при выполнении запроса (любого) данные (все) помещаются в специально выделенную в памяти область (дескриптор вывода XSQLDA). Для рассматриваемого случая FieldByName берет данные из этой области. При этом НД как такового нет, но есть возвращенные по выполнении запроса данные, лежащие там же.
Если говорить абстрактно-образно, то FieldByName эквивалентно ParamByName в данном случае.
Если есть сомнения в моих словах, то исходники доступны всем...

> При этом НД как такового нет, но есть возвращенные по выполнении запроса данные, лежащие там же.
если что-то выглядит как ..., пахнет как ..., ведет себя как ..., то это и есть ... оно.  неважно из какого места вышло.

рекорсет который не рекордет, но все функции кроме одной к нему применимы... надо же. выглядит как глюк, в логике, и код смотреть не надо. ADO ведет себя более "честно" если рекордсета нет, по опции "неполучения", то любая операция с ним вернет ошибку.... и ни каких неоднозначностей.

> Ega23 ©

все-таки FIB лучше купить. стоит копейки, а проблем очень многих можно избежать.

> а проблем очень многих можно избежать.
каких проблем? не вижу тут проблем. ну и впечатление по ветке, что Ega23 солидарен.

IB и FB очень отличаются. Это во первых. Во вторых FIB создают люди весьма знающие. В отличие от индусов (по крайней мере весьма похожие на них личности), которые пилят IBX

Есть еще UIB компоненты, но они в основном для серверов.

> IB и FB очень отличаются. Это во первых. Во вторых FIB создают
> люди весьма знающие. В отличие от индусов (по крайней мере
> весьма похожие на них личности), которые пилят IBX


Ещё раз. Назови мне хотя бы одну вескую причину перехода с IBХ на FIB+.
Типа: в FIB+ есть вот это вот, чего в IBX нет. Или оно работает неправильно и через опу.

А чего говорит IsEmpty?