Есть генератор, есть таблица.
На клиенте есть read-write транзакция + TIBSQL
Задача - вставить запись в таблицу и получить значение.
Код (условный):



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

Вопрос: как же так?

А если поставить не ShowMessage, а Application.ProcessMessages;?

И вообще? что за странная привычка пользоваться ShowMessage?
Скидывайте данные в лог/Label/Memo/Edit

if not Eof and not Bof
Когда-то наступал на эти грабли

> И вообще? что за странная привычка пользоваться ShowMessage?


Вов, ну естественно там не ShowMessage, это я так, для наглядности.

> Наткнулся на любопытное поведение TIBSQL

Если б мой заказчик не потерялся, я б тебя на эту фишку наткнул бы дней на десять ранее. :)

а поставить First; перед условием?
это может не от if not Eof, а от ExecQuery зависит, ведь не Open, же. (и кстати а если он?)

тут, имхо, та же фигня почему не люблю,  AdoQuery, ясности нет.

Кстати, да, если после ExecQuery поставить First - отрабатывает правильно?

> sniknik ©   (24.01.12 21:31) [5]
>
> а поставить First; перед условием?
> это может не от if not Eof, а от ExecQuery зависит, ведь
> не Open, же. (и кстати а если он?)

Метода Open у TIBSQL нет. (Сей компонент не является наследником TDataSet). Есть только свойство Open типа Boolean, но оно ReadOnly.
Имхо сей компонент предназначен только для DML-запросов. Правда на Select запросы он не ругается и даже порой работает. Даже в ситуации описанной Олегом. А порой не работает. И х.з. почему.
P.S. Сам работал с этим компонентом на Д2007.

> Имхо сей компонент предназначен только для DML-запросов.
>  Правда на Select запросы он не ругается и даже порой работает.


А Select - не DML?
DDL-запросы не пробовал, но оно мне и не надо.


> тут, имхо, та же фигня почему не люблю,  AdoQuery, ясности  нет.


Эта штука, скорее, некий аналог ADOCommand. С неким recordSet, который совсем не TDataSet. Но всякие Next, Eof, FieldByName - сохранены.

> Ega23 ©   (25.01.12 02:34) [8]
>
>
> > Имхо сей компонент предназначен только для DML-запросов.
>
> >  Правда на Select запросы он не ругается и даже порой
> работает.
>
>
> А Select - не DML?

А хрен его знает. Не люблю менагеров! :)

> Ega23 ©   (25.01.12 02:34) [8]
>
>
> > Имхо сей компонент предназначен только для DML-запросов.
>
> >  Правда на Select запросы он не ругается и даже порой
> работает.
>
>
> А Select - не DML?

Ну да.
Вот когда ткнут тебя мордой в ..., сразу вспоминаешь основы. Но только в том месте морды "которой ткнули".
А каким термином отличаются запросы на изменение от запросов на чтение?

> Но всякие Next, Eof, FieldByName - сохранены.
ну так как тогда насчет First; перед условием?

> ну так как тогда насчет First; перед условием?


Я проверю, просто не до этого сейчас.


> А каким термином отличаются запросы на изменение от запросов
> на чтение?


Запрос в [0] - это на чтение или на изменение? А если я ХП-шку дёргаю, которая сначала чё-та удаляет, потом что-то апдейтит, а потом селект огроменный выдаёт?
ИМХО, тут грань слишком тонка. Их как-то можно выделить в группы "возвращающая набор данных" и "не возвращающая набор данных". А уж что они там внутре из себя представляют - клиенту фиолетово.

Юзай FIB+..Это не реклама..купил, доволен. IBX отдыхают, разве что самому на РЕАКТОР заточить

> .купил, доволен.


Назови хотя бы одну объективную причину (а лучше - несколько) перехода со стандартных IB на FIB+?
При условии, что у меня нет ни одного DB-Aware компонента, нет ни одного TDataSource, и повсеместно ORM используется.

Boolean поля в Interbase 7 их отсутствие в FB...Где-то что-то не так...:)

Я о закладке Interbase и FireBird. Тот же SET TERM (Отсуствующий у IB кажись с "семерки")

> Boolean поля в Interbase 7 их отсутствие в FB...Где-то что-
> то не так...:)





Не вижу никаких проблем.

ну да.. это все равно что на светлобежевое говорить что оно белое..оно то примерно так...но разница есть. я не знал, что IBX ведут себя как FIB+(я о булевых полях)

> ну да.. это все равно что на светлобежевое говорить что
> оно белое..оно то примерно так.


Давай разберёмся.
В некоторых диалектах SQL (TSQL, например), есть тип bit. Фактически - 0 или 1. Причём, если у тебя в таблице 8 полей типа bit, то фактически эти 8 полей представляют из себя 1 байт (с битовой маской).
Это всё замечательно, пока не возникает троичная логика True/False/NULL.
Тут уже битом ну никак не обойтись.
Отсюда возникает вопрос: насколько так сильно необходим данный тип, если ты не можешь им пользоваться в полной мере?

Признаться, меня гораздо больше напрягает отсутствие типа byte, т.к. минимальным является smallint, а также явное отсутствие типа GUID (хотя Romkin говорил, что решаемо через collation. Но всё равно, хотелось бы автоматически).

Также вызывает некоторое недоумение (не напрягает абсолютно, но недоумение осталось), почему я могу создать последовательность только integer-значений. Почему не могу varchar, например? Или ещё какого другого типа? Ну там, timestamp?